Linking issue with Boost 1.44 and GCC 4.6
From what I can see the precompiled library from Hypertable is not finding
Hi, I'm having a very strange compilation issue with Boost. I've used boost in other C++ projects in the past and have had no issues. I'm writing a program to compile against Hypertable which relies on the boost 1.44 version of the library. I'm writing this on Intel Linux and compiling with GCC 4.6.3 Here is my linker command. I removed the .o's from my application to make it simpler to read: g++ -L/opt/hypertable/current/lib -L/home/l3/development/libraries/boost_1_44_0/stage/lib -pthread -o "AppLogger" MYDOT-O-FILES.o -lboost_system -lboost_iostreams -lboost_filesystem -lboost_program_options -lboost_thread -lsigar-x86-linux -lz -lHypertable -lHyperspace -lHyperTools -lHyperComm -lHyperCommon As you can see I'm including a number of boost libraries but I'm getting a lot of very strange errors. For example, opt/hypertable/current/lib/libHypertable.a(Client.cc.o): In function `Hypertable::Client::Client(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)': Client.cc:(.text+0x26a5): undefined reference to `boost::program_options::variables_map::variables_map()' the functions in the boost library. Here is another I get Client.cc:(.text+0x26a5): undefined reference to `boost::program_options::variables_map::variables_map()' /opt/hypertable/current/lib/libHypertable.a(Client.cc.o): In function `Hypertable::Client::Client(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)': I get a bunch of these: HqlInterpreter.cc:(.text._ZN5boost9call_onceIPFvvEEEvRNS_9once_flagET_[void boost::call_once<void (*)()>(boost::once_flag&, void (*)())]+0x151): undefined reference to `boost::detail::once_epoch_cv' There are many many more linker errors but I didn't want to clog up the system with all the errors. Any ideas would be greatly appreciated Thanks
AMDG On 10/20/2012 11:16 AM, Joseph Sulewski wrote:
I'm having a very strange compilation issue with Boost. I've used boost in other C++ projects in the past and have had no issues.
I'm writing a program to compile against Hypertable which relies on the boost 1.44 version of the library. I'm writing this on Intel Linux and compiling with GCC 4.6.3
Here is my linker command. I removed the .o's from my application to make it simpler to read: g++ -L/opt/hypertable/current/lib -L/home/l3/development/libraries/boost_1_44_0/stage/lib -pthread -o "AppLogger" MYDOT-O-FILES.o -lboost_system -lboost_iostreams -lboost_filesystem -lboost_program_options -lboost_thread -lsigar-x86-linux -lz -lHypertable -lHyperspace -lHyperTools -lHyperComm -lHyperCommon
Last time I checked, you need to put -lboost_program_options after the libraries that use it.
As you can see I'm including a number of boost libraries but I'm getting a lot of very strange errors. For example, opt/hypertable/current/lib/libHypertable.a(Client.cc.o): In function `Hypertable::Client::Client(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)': Client.cc:(.text+0x26a5): undefined reference to `boost::program_options::variables_map::variables_map()'
In Christ, Steven Watanabe
Steven, Thank you for the reply. It is definitely something order related. I took your advice and moved the boost_program_options to the end but now I get a lot of different errors. Is there any documentation that guides the order in which the boost libraries should be linked? Thanks, On Sun, Oct 21, 2012 at 10:05 AM, Steven Watanabe <watanabesj@gmail.com>wrote:
AMDG
On 10/20/2012 11:16 AM, Joseph Sulewski wrote:
I'm having a very strange compilation issue with Boost. I've used boost in other C++ projects in the past and have had no issues.
I'm writing a program to compile against Hypertable which relies on the boost 1.44 version of the library. I'm writing this on Intel Linux and compiling with GCC 4.6.3
Here is my linker command. I removed the .o's from my application to make it simpler to read: g++ -L/opt/hypertable/current/lib -L/home/l3/development/libraries/boost_1_44_0/stage/lib -pthread -o "AppLogger" MYDOT-O-FILES.o -lboost_system -lboost_iostreams -lboost_filesystem -lboost_program_options -lboost_thread -lsigar-x86-linux -lz -lHypertable -lHyperspace -lHyperTools -lHyperComm -lHyperCommon
Last time I checked, you need to put -lboost_program_options after the libraries that use it.
As you can see I'm including a number of boost libraries but I'm getting a lot of very strange errors. For example, opt/hypertable/current/lib/libHypertable.a(Client.cc.o): In function `Hypertable::Client::Client(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, unsigned int)': Client.cc:(.text+0x26a5): undefined reference to `boost::program_options::variables_map::variables_map()'
In Christ, Steven Watanabe _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Sun, Oct 21, 2012 at 01:55:48PM -0400, Joseph Sulewski wrote:
Steven,
Thank you for the reply. It is definitely something order related. I took your advice and moved the boost_program_options to the end but now I get a lot of different errors. Is there any documentation that guides the order in which the boost libraries should be linked?
Please do not top-post on the Boost lists. Linker command line ordering is largely due to historical reasons with ld-like linkers, and is considered a feature by some. In absence of the group options that changes scan behaviour, library resolution works roughly like this: The command line is scanned from left to right. Missing symbols are recorded as it scans. When something providing symbols is encountered, all missing symbols it can fulfil are filled and the rest are ignored. The end result is that if you list something that provides symbols too early on the command line, there's nothing that needs those symbols yet and they're all discarded. This is how traditional linking against static libraries work. Dynamic libraries are somewhat different, and newer toolchains have some changes in visiblity that may affect how links are performed. All in all, it's rarely wrong to play it safe and topologically sort your command line in dependency order. -- Lars Viklund | zao@acc.umu.se
On Sun, Oct 21, 2012 at 3:44 PM, Lars Viklund <zao@acc.umu.se> wrote:
On Sun, Oct 21, 2012 at 01:55:48PM -0400, Joseph Sulewski wrote:
Steven,
Thank you for the reply. It is definitely something order related. I took your advice and moved the boost_program_options to the end but now I get a lot of different errors. Is there any documentation that guides the order in which the boost libraries should be linked?
Please do not top-post on the Boost lists.
Linker command line ordering is largely due to historical reasons with ld-like linkers, and is considered a feature by some.
In absence of the group options that changes scan behaviour, library resolution works roughly like this:
The command line is scanned from left to right. Missing symbols are recorded as it scans. When something providing symbols is encountered, all missing symbols it can fulfil are filled and the rest are ignored.
The end result is that if you list something that provides symbols too early on the command line, there's nothing that needs those symbols yet and they're all discarded.
This is how traditional linking against static libraries work. Dynamic libraries are somewhat different, and newer toolchains have some changes in visiblity that may affect how links are performed.
All in all, it's rarely wrong to play it safe and topologically sort your command line in dependency order.
-- Lars Viklund | zao@acc.umu.se _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Lars, Thank you for the explanation The problem i'm facing is that I'm linking against a third party library and I don't know their dependencies. Is there a dependency order for the boost libraries? Thanks
On Sun, Oct 21, 2012 at 03:52:00PM -0400, Joseph Sulewski wrote:
On Sun, Oct 21, 2012 at 3:44 PM, Lars Viklund <zao@acc.umu.se> wrote:
All in all, it's rarely wrong to play it safe and topologically sort your command line in dependency order.
Lars,
Thank you for the explanation The problem i'm facing is that I'm linking against a third party library and I don't know their dependencies. Is there a dependency order for the boost libraries?
In general, Boost libraries tend to mention in the documentation what non-header-only dependencies they have. Otherwise, the simplest approach tends to be to try to link and find out what libraries the missing symbols come from based on their names. To my knowledge, there's no authorative central module dependency listing, but the Ryppl [1] lads sorted out a rough source-based dependency between libraries lately in order to modularise. [1] project with new build system, modularised Boost and heaven knows what else -- Lars Viklund | zao@acc.umu.se
participants (8)
-
Joseph Sulewski -
Lars Viklund -
Steven Watanabe