Here's the issue: the code I'm using uses a big library which links against boost. When I compile with static linking, everything works fine. However, when I try dynamic linking I get a bunch of undefined reference errors. The first thought was obviously "I am not linking the boost program_options" library, but I looked, and it is there in the linking command (and it comes after the library that needs it). Among the different errors, though, this stood out:
undefined reference to `_ZN5boost15program_options3argB5cxx11E
In my daily experience, linking errors are usually of the form "undefined reference to somefunction(...)". So I went to the installation folder of my boost library and used readelf to see what symbols I have in the library libboost_program.so. And in fact, that symbol does not appear. Instead, the closest I found is _ZN5boost15program_options3argE.
Google-ing a little bit, I found out that the extra part B5cxx11 is a new addition to the name mangling since C++11. It appears that boost (at least version 1.59.0) does not yet support this new name mangling.
So my question is: Is this a known issue? What workaround are there? And why does this issue not show up with static linking?
Edit: In case someone stumbles on this question in the future, I just tried boost 1.60.0, and the symbols contain the string B5cxx11. I believe (read: hope) this will solve the issue. As a double check, though, I am going to recompile again boost 1.59.0 to see if this is due to something I changed in my environment (although I doubt it).
This question was asked many moons ago, but since I already landed on this page I will pitch in with a possible solution.
You could try to compile your code with the -D_GLIBCXX_USE_CXX11_ABI=0 flag or define this macro: #define _GLIBCXX_USE_CXX11_ABI 0. See answers for this question for more details.
It's not that boost has to support it, your compiler/linker has. Probably your library was compiled with C++11 support and so was your boost, but your current program isn't. Try with the --std=c++11 option if you're on GCC.
Or maybe it's the other way around, and you're instantiating a template in your C++11 which uses C++11 name mangling and can't find library functions in the non-C++11-compiled boost (though that would border on compiler bug).
I have a similar problem recently. I recompile my boost library using the following commands
./b2 --build-dir=build/x86 address-model=32 threading=multi --toolset=gcc --layout=versioned --stagedir=./stage/x86 -j 8
./b2 --build-dir=build/x64 address-model=64 threading=multi --toolset=gcc --layout=versioned --stagedir=./stage/x64 -j 8
Then compile my program using
g++ main.cpp -L/home/research/boost_library/boost_1_68_0/stage/x64/lib/ -lboost_program_options-gcc82-mt-x64-1_68
This solves my problem. I am using gcc 8.2 on redhat linux
Related
I need to link my SO against libbfd, for the purpose of having human-readable backtraces.
Static linking against libbfd.a fails, because it's not compiled with -fPIC, so as I understand, it can participate in executable only.
Though linking against libbfd.so also gives some troubles.
I need to compile on both Ubuntu-14.04 and Debian Wheezy 7.8
And they have non-intersecting sets of binutils versions. In particular, Ubuntu has 2.24, and Debian has 2.22 and 2.25. And the problem is, gcc doesn't want to take symlink's name libbfd.so to reference it, and uses SONAME instead. So i end with either libbfd-2.24-system.so or libbfd-2.25-system.so in dependencies.
For now I see several approaches:
There's some hidden flag which allows to override SONAME during linking. This is the preferred path
I have no way other than compile libbfd by hand. I would evade this as much as possible.
Manual dlopen+dlsym for everything I need.
I read answer gcc link shared library against symbolic link, but it suggests to change SONAME I'm not able to do.
Any suggestions?
Thanks.
EDIT: it seems that virtually all static libs in Ubuntu repos are not position-independent. Can't guess why. With the inability to override SONAME it makes things much more complicated.
Not sure whether i understand your (4 years old problem) correctly, but having similar problems with libbfd, I found this solution:
Using the linker flag -lbfd seems to work.
It is a linker flag that specifies g++ to link against libbfd.
My full command was g++ loader.cc -lbfd.
At least for me, errors at link-time a la "unknown function" are solved.
I'm currently trying to link a unit test using the boost unit testing framework. When it came to compiling my code, I immediately found myself googling "how to link boost unit tests", and sure enough, someone has had that same question.
But the fact that I've used a library for over a year now, frequently visit the documentation, and still don't know where to find the linker flags is a terrible thing. I've read the boost documentation which ostensibly answers this question, but didn't find the answer there.
If I want to build my program using boost library x, how do I find out which flag to give the linker to actually link it?
Most Boost libraries are header only, so all you have to do is #include them in your code and tell the compiler where to find them (-I). For those that actually need linking, your linker flags are where to find the lib (-L) and what to link (for library libx use the linker flag -lx)
I am trying to compile some code for an STM32 chip using CodeBench G++ Lite tools. However, it generates an error.
startup.o: In function `LoopFillZerobss':
(.text.Reset_Handler+0x2a): undefined reference to `__libc_init_array'
I have googled and it appears that libc_init_array is probably part of some standard gcc library...but I am not sure how to fix this error?
I also have errors such as this
arm-none-eabi-ld: cannot find libc.a
and similarly for libgcc.a and libm.a
The function __libc_init_array is part of CodeSourcery's 'CS3' mechanism for 'start up' code which ensures all of a programs static initialisation happens before main is executed.
Start by ensuring all of the libraries are found. That might be enough to fix all your problems.
One approach is to use arm-none-eabi-g++, and not use arm-none-eabi-ld directly, to do the linking because g++ should correctly pass some important parameters to arm-none-eabi-ld. In some case, that might be all that is needed to find and link the correct libraries.
If you aren't sure how to build on the command line, or arm-none-eabi-g++ isn't doing everything to resolve the missing libraries, go and have a look at LeafLabs web site, where they show how build from the command line using Makefiles
http://leaflabs.com/docs/unix-toolchain.html
They provide a free, Open Source, IDE for STM32, built for Windows, Linux and Mac, which includes a working gcc-based toolchain for each of those platforms, and enough of the libraries to get started http://leaflabs.com/docs/maple-ide-install.html
Even if you'd prefer to use your toolchain for the actual build, it may be worth using theirs, with their Makefiles, to sanity check the process you are using to build your program.
I am not a member of LeafLabs staff, and have no relationship with the company other than I have bought some of their products, and try to answer questions on their forum.
This seems to be a recurring issue.
I use a combination of CUDA and Boost libraries. The works fine e.g. for some Boost libraries. If I try to include boost/math/special_functions.hpp, I get errors like:
argument of type "_v1di" is incompatible with parameter of type
"_attribute((vector_size(8))) long"
Any advice would be helpful
NVCC support in boost is still unstable. Most heavy TMP based code are susceptible to failure. As a maintainer of the NVCC support in boost, i urge you to report the error to the Boost SVN Trac so we can handle it
This is not a direct answer to solve this specific problem, but a more general one. I'm assuming here you use NVCC to compile your code which includes the Boost header. Passing heavily templated code through NVCC sometimes causes problems. Make sure you're using the very latest version of NVCC. Template support keeps improving and you might just get lucky with an update.
Otherwise, you might want to devise a way to split your code into a part using Boost which won't need to go through NVCC and CUDA specific code which does.
I'm trying to migrate a project which uses Boost (particularly boost::thread and boost::asio) to VxWorks.
I can't get boost to compile using the vxworks gnu compiler. I figured that this wasn't going to be an issue as I'd seen patches on the boost trac that purport to make this possible, and since the vxworks compiler is part of the gnu tool chain I should be able to follow the directions in the boost docs for cross compilation.
I'm building on windows for a ppc vxworks.
I changed the user-config.jam file as specified in the boost docs, and used the target-os=linux option to bjam, but bjam appears to hang before it can compile. Closer inspection of the commands issued by bjam (by invoking it using the -n option) reveal that it's trying to compile with boost::thread's win32 files. This can't be right, as vxworks uses pthreads.
My bjam command: .\bjam --with-thread toolset=gcc-ppc target-os=linux gcc-ppc is set in user-config to point to the g++ppc vxworks cross compiler.
What am I doing wrong? I believe I have followed the docs to the letter.
If it's #including win32 headers instead of the pthread ones, there could be a discrepancy between the set of macros your compiler is defining and the macros the boost headers are checking for. I had a problem like that with the smart pointer headers, which in an older version of boost would check for __ppc but my compiler defined __ppc__ (or vice versa, can't remember).
touch empty.cpp
ccppc -dD -E empty.cpp
That will show you what macros are predefined by your compiler.
I never tried to compile boost for VxWorks, since I only needed a few of the headers.
Try also adding
threadapi=pthread
The documentation you mention is for Boost.Build -- which is standalone build tool -- and the above flag is something specific to Boost.Thread library. What do you mean by "hang"? Because Boost libraries are huge, it sometimes take a lot of time to scan dependencies prior to build.
If it actually hangs, can you catch bjam in a debugger and produce a backtrace? Also, log of any output will help.