I just wanted to note here that I tried compiling Boost.Log from trunk without success when using clang / libc++. The command to compile is (after copying boost.log folders into boost-trunk):
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-07-29
I also use libc++, it compiles fine for me on both 1.49 and 1.50. This is the command that I use:
./b2 toolset=clang cxxflags="-stdlib=libc++" linkflags="-stdlib=libc++" -build-type=complete -layout=tagged
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-07-29
forgot to add that I only have those libs available:
/opt/local/lib/libboost_log-d.a
/opt/local/lib/libboost_log-d.dylib
/opt/local/lib/libboost_log-s.a
/opt/local/lib/libboost_log-sd.a
/opt/local/lib/libboost_log.a
/opt/local/lib/libboost_log.dylib
some of other type are failing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-07-29
Just to let you know that. Under 1.49, log compiles fine and link fine. But under 1.50, log compiles fine but link fails.
@ reakin: This is a problem with clang (or libc++) or, less likely, with Boost.Xpressive. You should report it to the respective team.
@ the other guy: I'm not sure what exactly is going on. Make sure you recompiled Boost.Log and the compilation succeeded. If it did, check out what symbols the library exports.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think that clang or libc++ might very well be the one to blame, but I can't diagnose what the problem is here since this is the first time I've looked at Boost.Log. Is there any way we can simplify or create an example that reproduces these errors, that can be discussed on the clang mailing list? I've done this with other compile errors related to type_traits and found some bugs..
I think my post above misses the first compile error to occur, so I have rebuild using (notice no libc++):
./b2 -q -a toolset=clang
The first error to occur is:
libs/log/src/core.cpp:370:19: error: use of overloaded operator '=' is ambiguous (with operand types 'filter_type' (aka 'light_function1<bool, const values_view_type &>') and 'const filter_type' (aka 'const light_function1<bool, const values_view_type &>'))
pImpl->Filter = filter;
~~~~~~~~~~~~~ ^ ~~~~~~
libs/log/src/core.cpp:579:33: note: in instantiation of member function 'boost::log2_mt_posix::basic_core<char>::set_filter' requested here
template class BOOST_LOG_EXPORT basic_core< char >;
^
./boost/log/detail/light_function.hpp:171:32: note: candidate function
BOOST_LOG_LWFUNCTION_NAME& operator= (BOOST_COPY_ASSIGN_REF(this_type) that)
^
./boost/log/detail/light_function.hpp:178:32: note: candidate function
BOOST_LOG_LWFUNCTION_NAME& operator= (int p)
^
libs/log/src/core.cpp:386:29: error: use of overloaded operator '=' is ambiguous (with operand types 'exception_handler_type' (aka 'light_function0<void>') and 'const exception_handler_type' (aka 'const light_function0<void>'))
pImpl->ExceptionHandler = handler;
~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~
libs/log/src/core.cpp:579:33: note: in instantiation of member function 'boost::log2_mt_posix::basic_core<char>::set_exception_handler' requested here
template class BOOST_LOG_EXPORT basic_core< char >;
^
./boost/log/detail/light_function.hpp:332:32: note: candidate function
BOOST_LOG_LWFUNCTION_NAME& operator= (BOOST_COPY_ASSIGN_REF(this_type) that)
^
./boost/log/detail/light_function.hpp:339:32: note: candidate function
BOOST_LOG_LWFUNCTION_NAME& operator= (int p)
^
libs/log/src/core.cpp:370:19: error: use of overloaded operator '=' is ambiguous (with operand types 'filter_type' (aka 'light_function1<bool, const values_view_type &>') and 'const filter_type' (aka 'const light_function1<bool, const values_view_type &>'))
pImpl->Filter = filter;
~~~~~~~~~~~~~ ^ ~~~~~~
libs/log/src/core.cpp:582:33: note: in instantiation of member function 'boost::log2_mt_posix::basic_core<wchar_t>::set_filter' requested here
template class BOOST_LOG_EXPORT basic_core< wchar_t >;
^
./boost/log/detail/light_function.hpp:171:32: note: candidate function
BOOST_LOG_LWFUNCTION_NAME& operator= (BOOST_COPY_ASSIGN_REF(this_type) that)
^
./boost/log/detail/light_function.hpp:178:32: note: candidate function
BOOST_LOG_LWFUNCTION_NAME& operator= (int p)
^
libs/log/src/core.cpp:386:29: error: use of overloaded operator '=' is ambiguous (with operand types 'exception_handler_type' (aka 'light_function0<void>') and 'const exception_handler_type' (aka 'const light_function0<void>'))
pImpl->ExceptionHandler = handler;
~~~~~~~~~~~~~~~~~~~~~~~ ^ ~~~~~~~
libs/log/src/core.cpp:582:33: note: in instantiation of member function 'boost::log2_mt_posix::basic_core<wchar_t>::set_exception_handler' requested here
template class BOOST_LOG_EXPORT basic_core< wchar_t >;
^
./boost/log/detail/light_function.hpp:332:32: note: candidate function
BOOST_LOG_LWFUNCTION_NAME& operator= (BOOST_COPY_ASSIGN_REF(this_type) that)
^
./boost/log/detail/light_function.hpp:339:32: note: candidate function
BOOST_LOG_LWFUNCTION_NAME& operator= (int p)
^
4 errors generated.
I can successfully compile with the default toolset ('darwin'), but the rest of my toolchain is using clang, so I'm stuck trying to get it to work.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oops, I accidentally left out the -std=c++11 flag too. Thanks for the commit, but I should mentioned that I tried again without C++11 and it still fails with the same error "use of use of overloaded operator '=' is ambiguous".
I actually found out I wasn't able to build boost::chrono, and I was able to before, so at that time I scratched my current copy of boost and started over from 1.50 - with success compiling Boost.Log. So, I'm really not sure what the root of these errors were… sorry if it was a waste of time. Thanks for the help, nonetheless!
Cheers,
Rich
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately I have to add that after trying to integrate Boost.Log into my project, I found that the binary supporting clang / libc++, whichI thought had successfully compiled, actually had missing symbols. I recompiled and looked at the log and, although I used the '-q' parameter to b2, there are still quite a few errors in there (somewhat masked by the many warnings for unused parameters). I don't think my linked .a lib is good, but I'll list the code and resulting errors here anway, if nothing more than a log what a user tried:
#include<boost/log/common.hpp>#include<boost/log/utility/init/to_console.hpp>namespacelogging=boost::log;namespacefmt=boost::log::formatters;namespaceflt=boost::log::filters;namespacesinks=boost::log::sinks;namespaceattrs=boost::log::attributes;namespacesrc=boost::log::sources;namespacekeywords=boost::log::keywords;voidtest_logging(){// This is a simple tutorial/example of Boost.Log usage// The first thing we have to do to get using the library is// to set up the logging sinks - i.e. where the logs will be written to.logging::init_log_to_console(std::clog,keywords::format="%TimeStamp%: %_%");}
[r@Richards-MacBook-Pro xcode (master *)]$ lipo -info ../lib/macosx/libboost_log.a
input file ../lib/macosx/libboost_log.a is not a fat file
Non-fat file: ../lib/macosx/libboost_log.a is architecture: i386
I'm really looking forward to using this, even more looking forward to it being integrated within the official boost package, but sadly I have to result to a header-only logging library until I can resolve these compile/linking errors.
However thank you again for all the help and such a thorough implementation!
Cheers,
Rich
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2012-09-25
Any news about this error ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I ran into the exact same error. I got a quick fix for people who does not use the regular expression syntax. Simply change the on_custom_relation member function in /libs/log/src/default_filter_factory.cpp like this:
The root of the issue seems to be with clang or libc++ like previously mentioned. Somehow, the
std::is_nothrow_move_assignable<T>::value
member variable is not defined when
T=regex_t
as defined in the memer function.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-03-04
I've seen this particular missing symbols error when compiling on OS X using clang, with the -std=c++11 -stdlib=libc++ flags.
Interestingly, linking against the static .a libraries works fine; it's only linking against the dynamic .dylib libraries that's problematic. I'm starting to look into this now, but thought I'd mention it here first just in case the solution was immediately obvious to someone.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-03-04
Followup; it's some issue with the b2-driven dylib creation. I was able to fix it manually by simply extracting the .o files from the .a files, and rebuilding the dylib. e.g., for libboost_log.dylib:
Results in a dylib with all symbols present. Repeating the same process with the setup library resolves the undefined symbols issue in my case when using the dylibs. I am not sure yet where the b2 build is going sideways, but at least this gets me functional dynamic libraries.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's not right. The library mangles symbols differently in static and dynamic builds. Most likely you are building your application without BOOST_ALL_DYN_LINK or BOOST_LOG_DYN_LINK defined and only have dylib.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2013-03-04
Yes, you're absolutely correct. Defining BOOST_LOG_DYN_LINK in the application resolved the linker issues.
I am a bit curious, though; to my knowledge, the other boost libraries don't require something like this, which is what led me astray in the first place, so it was surprising to find it worked in this way.
I'd guess others would be likely to fall into the same trap as well, as on at least a few platforms the dynamic libs will be built and installed by default, and will be preferred by the linker when found in the same location as a static library, so the default case in this case is the one that doesn't work properly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unlike other Boost libraries, Boost.Log is very sensitive to configuration errors. The difference in name mangling is intended to prevent possible errors when one part of the application is linked with static lib and the other one with dynamic lib. On Windows, for example, symbols are already mangled differently, even without the effort on the library part, so this behavior is not something special across the board.
That said, it's worth documenting. You're not the first one to encounter this problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just wanted to note here that I tried compiling Boost.Log from trunk without success when using clang / libc++. The command to compile is (after copying boost.log folders into boost-trunk):
And here is the compile output, where the errors start (quite a way in):
I also use libc++, it compiles fine for me on both 1.49 and 1.50. This is the command that I use:
./b2 toolset=clang cxxflags="-stdlib=libc++" linkflags="-stdlib=libc++" -build-type=complete -layout=tagged
forgot to add that I only have those libs available:
/opt/local/lib/libboost_log-d.a
/opt/local/lib/libboost_log-d.dylib
/opt/local/lib/libboost_log-s.a
/opt/local/lib/libboost_log-sd.a
/opt/local/lib/libboost_log.a
/opt/local/lib/libboost_log.dylib
some of other type are failing.
Just to let you know that. Under 1.49, log compiles fine and link fine. But under 1.50, log compiles fine but link fails.
arh, i am sorry, I didn't see you are compiling from the trunk. please ignore my previous comments.
@ reakin: This is a problem with clang (or libc++) or, less likely, with Boost.Xpressive. You should report it to the respective team.
@ the other guy: I'm not sure what exactly is going on. Make sure you recompiled Boost.Log and the compilation succeeded. If it did, check out what symbols the library exports.
I think that clang or libc++ might very well be the one to blame, but I can't diagnose what the problem is here since this is the first time I've looked at Boost.Log. Is there any way we can simplify or create an example that reproduces these errors, that can be discussed on the clang mailing list? I've done this with other compile errors related to type_traits and found some bugs..
I think my post above misses the first compile error to occur, so I have rebuild using (notice no libc++):
./b2 -q -a toolset=clang
The first error to occur is:
I can successfully compile with the default toolset ('darwin'), but the rest of my toolchain is using clang, so I'm stuck trying to get it to work.
I'm not sure if it helps but I've committed a change that should resolve ambiquity if your compiler supports nullptr.
Oops, I accidentally left out the -std=c++11 flag too. Thanks for the commit, but I should mentioned that I tried again without C++11 and it still fails with the same error "use of use of overloaded operator '=' is ambiguous".
I actually found out I wasn't able to build boost::chrono, and I was able to before, so at that time I scratched my current copy of boost and started over from 1.50 - with success compiling Boost.Log. So, I'm really not sure what the root of these errors were… sorry if it was a waste of time. Thanks for the help, nonetheless!
Cheers,
Rich
Unfortunately I have to add that after trying to integrate Boost.Log into my project, I found that the binary supporting clang / libc++, whichI thought had successfully compiled, actually had missing symbols. I recompiled and looked at the log and, although I used the '-q' parameter to b2, there are still quite a few errors in there (somewhat masked by the many warnings for unused parameters). I don't think my linked .a lib is good, but I'll list the code and resulting errors here anway, if nothing more than a log what a user tried:
And linking error:
For good measure:
I'm really looking forward to using this, even more looking forward to it being integrated within the official boost package, but sadly I have to result to a header-only logging library until I can resolve these compile/linking errors.
However thank you again for all the help and such a thorough implementation!
Cheers,
Rich
Any news about this error ?
No. I'm not using Mac OS X, so unless someone provides patches I don't think this will be fixed any time soon.
Hi, I ran into the exact same error. I got a quick fix for people who does not use the regular expression syntax. Simply change the on_custom_relation member function in /libs/log/src/default_filter_factory.cpp like this:
This is a dirty fix but it works.
The root of the issue seems to be with clang or libc++ like previously mentioned. Somehow, the
member variable is not defined when
as defined in the memer function.
I've seen this particular missing symbols error when compiling on OS X using clang, with the -std=c++11 -stdlib=libc++ flags.
Interestingly, linking against the static .a libraries works fine; it's only linking against the dynamic .dylib libraries that's problematic. I'm starting to look into this now, but thought I'd mention it here first just in case the solution was immediately obvious to someone.
Followup; it's some issue with the b2-driven dylib creation. I was able to fix it manually by simply extracting the .o files from the .a files, and rebuilding the dylib. e.g., for libboost_log.dylib:
ar -x libboost_log.a
clang++ -dynamiclib -std=c++11 *.o -o libboost_log.dylib -stdlib=libc++ -L/usr/local/lib -lboost_thread -lboost_system -lboost_filesystem
Results in a dylib with all symbols present. Repeating the same process with the setup library resolves the undefined symbols issue in my case when using the dylibs. I am not sure yet where the b2 build is going sideways, but at least this gets me functional dynamic libraries.
That's not right. The library mangles symbols differently in static and dynamic builds. Most likely you are building your application without BOOST_ALL_DYN_LINK or BOOST_LOG_DYN_LINK defined and only have dylib.
Yes, you're absolutely correct. Defining BOOST_LOG_DYN_LINK in the application resolved the linker issues.
I am a bit curious, though; to my knowledge, the other boost libraries don't require something like this, which is what led me astray in the first place, so it was surprising to find it worked in this way.
I'd guess others would be likely to fall into the same trap as well, as on at least a few platforms the dynamic libs will be built and installed by default, and will be preferred by the linker when found in the same location as a static library, so the default case in this case is the one that doesn't work properly.
Unlike other Boost libraries, Boost.Log is very sensitive to configuration errors. The difference in name mangling is intended to prevent possible errors when one part of the application is linked with static lib and the other one with dynamic lib. On Windows, for example, symbols are already mangled differently, even without the effort on the library part, so this behavior is not something special across the board.
That said, it's worth documenting. You're not the first one to encounter this problem.