I compiled boost 1.54 with gcc version 4.6.3( in 3.2.0-29-generic #46-Ubuntu ). Then, I developed my library using this boost library. Since I don't want to recompile boost every time I change my library, I added compiled static libraries of boost to my git repo.
Now, I am trying to compile my library in a different machine with different version compiler (tried with gcc 4.4 and gcc 4.7). My library compiles fine, but when it comes to linking it is printing following errors.
`.text._ZN5boost16exception_detail10bad_alloc_D2Ev' referenced in section `.text._ZN5boost16exception_detail10bad_alloc_D1Ev[boost::exception_detail::bad_alloc_::~bad_alloc_()]' of ../external/lib/linux/64/libboost_thread.a(thread.o): defined in discarded section `.text._ZN5boost16exception_detail10bad_alloc_D2Ev[_ZN5boost16exception_detail10bad_alloc_D5Ev]' of ../external/lib/linux/64/libboost_thread.a(thread.o)
`.text._ZN5boost16exception_detail14bad_exception_D2Ev' referenced in section `.text._ZN5boost16exception_detail14bad_exception_D1Ev[boost::exception_detail::bad_exception_::~bad_exception_()]' of ../external/lib/linux/64/libboost_thread.a(thread.o): defined in discarded section `.text._ZN5boost16exception_detail14bad_exception_D2Ev[_ZN5boost16exception_detail14bad_exception_D5Ev]' of ../external/lib/linux/64/libboost_thread.a(thread.o)
`.text._ZN5boost16exception_detail19error_info_injectorINS_21thread_resource_errorEED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorINS_21thread_resource_errorEED1Ev[boost::exception_detail::error_info_injector<boost::thread_resource_error>::~error_info_injector()]' of ../external/lib/linux/64/libboost_thread.a(thread.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorINS_21thread_resource_errorEED2Ev[_ZN5boost16exception_detail19error_info_injectorINS_21thread_resource_errorEED5Ev]' of ../external/lib/linux/64/libboost_thread.a(thread.o)
`.text._ZN5boost16exception_detail19error_info_injectorINS_10lock_errorEED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorINS_10lock_errorEED1Ev[boost::exception_detail::error_info_injector<boost::lock_error>::~error_info_injector()]' of ../external/lib/linux/64/libboost_thread.a(thread.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorINS_10lock_errorEED2Ev[_ZN5boost16exception_detail19error_info_injectorINS_10lock_errorEED5Ev]' of ../external/lib/linux/64/libboost_thread.a(thread.o)
`.text._ZN5boost16exception_detail19error_info_injectorINS_15condition_errorEED2Ev' referenced in section `.text._ZN5boost16exception_detail19error_info_injectorINS_15condition_errorEED1Ev[boost::exception_detail::error_info_injector<boost::condition_error>::~error_info_injector()]' of ../external/lib/linux/64/libboost_thread.a(thread.o): defined in discarded section `.text._ZN5boost16exception_detail19error_info_injectorINS_15condition_errorEED2Ev[_ZN5boost16exception_detail19error_info_injectorINS_15condition_errorEED5Ev]' of ../external/lib/linux/64/libboost_thread.a(thread.o)
collect2: ld returned 1 exit status
make[2]: *** [libHazelcastClientShared_64.so] Error 1
make[1]: *** [CMakeFiles/HazelcastClientShared_64.dir/all] Error 2
make: *** [all] Error 2
PS: I tried to compile with a different machine with same compiler version also. (gcc version 4.6.3 and Centos 6.4)
Most Boost libraries are header-only: they consist entirely of header files containing templates and inline functions, and require no separately-compiled library binaries or special treatment when linking.
Boost Libraries are intended to be widely useful, and usable across a broad spectrum of applications. For example, they are helpful for handling large numbers having a range beyond the long long, long double data type (264) in C++.
The principles used to design the STL are built upon and expanded on by the Boost libraries.
To install the newest Boost version (including all libraries), you need to download the latest source code from Boost website (currently the latest version is 1.69. 0). Now you need to specify where to put the included headers and libraries, after compiling the source code.
The c++ ABI is not gauranteed to be consistent across different compiler versions. This affects the c++ name mangling and could cause the linker errors you are seeing. You have to use the same version of gcc for all libs.
The best would be to keep your whole system on the latest supported version of gcc. If your users really require different compilers then you can supply different versions of your library - one for each compiler you want to support.
Linking with libraries compiled with different compilers is not gauranteed to work. This is true for both static and shared/dynamic c++ libs.
Also have a look at: Have a look at Unusual C++ linker error - 'Defined in discarded section' It seems that the accepted answer to that question was also to compile all the libraries with the same version of GCC.
Boost is riddled with conditional compilation blocks based on the availability or support of different features by the compiler. See their macro list. Different compilers (or versions) have different levels of support for different standard features (or extensions). The Boost libraries are a mix of code that tailors to the least common denominator (when it doesn't "hurt" the code), compiler-specific workarounds, and conditional use of features that, when supported, can provide a clear benefit.
I am very inclined to believe that this is what is causing the issue. When you first compiled to code for a particular compiler and platform, certain switches were turned on and others turned off depending on what that platform supported, leading to a binary library that only really works for that platform. Then, when you tried to compiler your code on another platform, different switches were turned on/off within the boost headers, leading to incompatibilities at link-time.
Long story short, you cannot do what you are trying to do, at least, not without quite a bit of work. One solution would be to figure out what boost macros (from the list I linked to) are turned on or off on the least capable platform, and then, manually define those macros in your code to enforce an identical compilation on all platforms. But this could be labour-intensive.
Boost has very good and wide-spread distribution (of binaries too). So, I wouldn't worry too much about being able to install the boost binaries on different platforms.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With