I have a problem linking boost.asio. It uses boost.system and the linker errors start with:
/boost_1_39_0/boost/system/error_code.hpp:205: undefined reference to `boost::system::get_system_category()'
which means I need to link boost.system. I already built boost and I have now several lib files.
boost_system-mgw32-d-1_39.dll and lib
libboost_system-mgw34-d-1_39.lib
libboost_system-mgw34-mt-d-1_39.lib
libboost_system-mgw34-sd-1_39.lib
and some more. How do I link them? Which one do I use? Do I copy all of them together?
My system is win32+mingw+eclipse cdt+qt 4.5.2+qt integration for eclipse. I already learned that I need to at a LIBS= section to my .pro file.
Can you give my some hints?
Thank you.
The libraries are named based on whether or not multi-threading support is enabled, static and dynamic linkage, debug and release mode, and more. Here's some details:
http://www.boost.org/doc/libs/1_39_0/more/getting_started/unix-variants.html#library-naming
I'm not sure about eclipse as I don't use it, but with gcc (and mingw) you need to specify both a directory to find the libraries in (-L) and the file to link with. For example, if you wanted to link with the single-threaded debug version:
-L/path/to/libraries -lboost_system-mgw34-sd-1_39
Related
I wrote a tiny program that requires some libraries including libboost_filesystem, libboost_program_options and libcurl.
I compiled it on my home machine and took the binary to my computer at work to test it there. But there it gives the following error message when I try to start the program:
error while loading shared libraries:
libboost_filesystem.so.1.42.0: cannot
open shared object file
But when I search for this file I see that it exists in:
/usr/lib/libboost_filesystem.so.1.42.0
Did I something wrong during the compilation / linking of my program? If yes what do I have to do to make it work on other machines?
First, try to issue ldconfig -p | grep libboost_filesystem.so in a console to make sure the library is in your ld cache.
If it is not, you may need to add a file with a name like boost.conf to your /etc/ld.so.conf.d directory. This file should contain a path to your boost libraries. Then run sudo ldconfig to update your system's ld cache.
Hope this will help...
Looks like you need to statically link the library. Here's a good explanation. Boost static linking
Did you link against the same version of the boost_filesystem library? Depending on how you compile your application, it requires the very same version of the library to be present.
You could try to check for what your application actually looks for with:
ldd <your app name>
Probably check your LD_LIBRARY_PATH environment variable as well.
Could you make sure that /usr/lib/libboost_filesystem.so.1.42.0 is not a dead link ?
Did you compile the shared binaries of boost and provided them to the user?
Often boost can be used without any binary/shared to provide. But if you use, for example, boost::filesystem, you'll have to build the binaries, as lib or shared object, and make sure it's available to the final executable shared binary search path.
You can find an explaination and more details in the boost documentation. Here is the linux version : http://www.boost.org/doc/libs/1_44_0/more/getting_started/unix-variants.html
From this page :
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.
...
The only Boost libraries that must be
built separately are:
Boost.Filesystem
Boost.GraphParallel
Boost.IOStreams
Boost.MPI
Boost.ProgramOptions
Boost.Python (see
the Boost.Python build documentation
before building and installing it)
Boost.Regex
Boost.Serialization
Boost.Signals
Boost.System
Boost.Thread
Boost.Wave
is /usr/lib in your LD_LIBRARY_PATH environment variable?
I have a C++ file a.cpp with the library dependency in the path /home/name/lib and the name of the library abc.so.
I do the compilation as follows:
g++ a.cpp -L/home/name/lib -labc
This compiles the program with no errors.
However while running the program, I get the ERROR:
./a.out: error while loading shared libraries: libabc.so.0: cannot open shared object file: No such file or directory
However if before running the program, I add the library path as
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/name/lib;
and compile and run now, it works fine.
Why am I not able to link the library by giving it from the g++ command?
Because shared object libraries are linked at runtime - you either need to add the location to the library search path (as you've done), place it somewhere within an already existing path (like /usr/lib), or add a symbolic link to an existing library path that links to the location where it exists.
If you want to compile the library in so there is no runtime dependency, you'll need a static library (which would be abc.a) - note that this has numerous downsides, however (if the library is updated, you'll need to recompile your executable to incorporate that update).
Why am I not able to link the library by giving it from the g++ command?
You are able to link, and you did link the library succesfully. Otherwise you would not be able to build executable (in your case a.out). The problem you mixed 2 different things: linking with shared libraries and loading them at runtime. Loading shared libraries is a pretty complex concept and described pretty well here Program-Library-HOWTO read from 3.2.
You are linking dynamically, is the default behavior with GCC. LD_LIBRARY_PATH is used to specify directories where to look for libraries (is a way of enforce using an specific library), read: Program-Library-HOWTO for more info. There is also an ld option -rpath to specify libraries search path for the binary being compiled (this info is written in the binary and only used for that binary, the LD_LIBRARY_PATH affect other apps using the same library, probably expecting a new or old version).
Linking statically is possible (but a little tricky) and no dependency would be required (but sometimes is not recommended, because prevent the update of the dependent libraries, for example for security reason, in static linking your always are using the versions of the libraries you have when compiled the binary).
I wrote a static library (compiled with TDM-gcc 4.8.1 in Windows 7 for x64) that has dependencies on other static libraries. Boost libraries (locale and system) to be specific.
Since I'm building a static library I assumed that the libraries I'm dependend on would automatically included in my final .a, especially since I'm using them in my code.
But when I'm trying to build an executable that statically links to my aforementioned library there are still undefined references to some boost parts, that are definitely used in my library.
Is there a way to fix that?
Any help is gladly appreciated. Thank you
Edit:
I haven't been careful enough, because I now know what causes the problem. I'm using codeblocks and all the necessary arguments for building the archive are declared in the project prooperties. But codeblocks doesn't even call the linker when building my library. Instead it calls ar.exe and passes all object files of my project. That way, no external library are ever included. So, I have too look for away to tell codeblocks to build the library in the right way..
Your executable needs to link against all the relevant libraries, including the ones it directly depends on, plus the ones it indirectly depends on. When you link a static library you typically do not embed other static libraries within it.
I'm trying to port/build some of my code written for gcc (on linux) as a dll on windows. First I tried to build in under VC++ but there were so many errors/warnings (mainly in VC's own include files, which didn't really make much sense to me :)) so I installed MinGW distro (which includes Boost libraries). Compilation went quite smoothly, however linking failed with undefined references to functions from boost libraries. The "-t" parameter showed that the linker doesn't actually use the boost libraries for some reason (yes, the -L path is correct, the libraries are there, linker doesn't complain when I use -l).
After much googling I found out that the order is the problem, that I have to place my -l parameters after all my .o files (because of dependencies). This seemed to solve all the problems except one undefined reference to thread library. Again -t showed that this library is actually not used by the linker (not in the list) the others are (I use boost_system and boost_date_time as well). I played with the order of the parameters again but the result was the same. Any idea what am I missing?
The error is:
c:/x5/cpp/build//timed_cond.o:timed_cond.cpp:(.text$_ZN5boost6detail24basic_condition_variable7do_waitINS_11unique_lockINS_5mutexEEEEEbRT_NS0_7timeoutE[bool boost::detail::basic_condition_variable::do_wait<boost::unique_lock<boost::mutex> > (boost::unique_lock<boost::mutex>&, boost::detail::timeout)]+0x246): undefined reference to `_imp___ZN5boost11this_thread18interruptible_waitEPvNS_6detail7timeoutE'
I use same versions of Boost library (1.44.0) on both platforms
Ok, I found the answer. Looks like the problem is in boost libraries being static in MinGW-distro. Normally they are configured to be linked dynamically and that caused above issue. This answer explains it...
I wrote a tiny program that requires some libraries including libboost_filesystem, libboost_program_options and libcurl.
I compiled it on my home machine and took the binary to my computer at work to test it there. But there it gives the following error message when I try to start the program:
error while loading shared libraries:
libboost_filesystem.so.1.42.0: cannot
open shared object file
But when I search for this file I see that it exists in:
/usr/lib/libboost_filesystem.so.1.42.0
Did I something wrong during the compilation / linking of my program? If yes what do I have to do to make it work on other machines?
First, try to issue ldconfig -p | grep libboost_filesystem.so in a console to make sure the library is in your ld cache.
If it is not, you may need to add a file with a name like boost.conf to your /etc/ld.so.conf.d directory. This file should contain a path to your boost libraries. Then run sudo ldconfig to update your system's ld cache.
Hope this will help...
Looks like you need to statically link the library. Here's a good explanation. Boost static linking
Did you link against the same version of the boost_filesystem library? Depending on how you compile your application, it requires the very same version of the library to be present.
You could try to check for what your application actually looks for with:
ldd <your app name>
Probably check your LD_LIBRARY_PATH environment variable as well.
Could you make sure that /usr/lib/libboost_filesystem.so.1.42.0 is not a dead link ?
Did you compile the shared binaries of boost and provided them to the user?
Often boost can be used without any binary/shared to provide. But if you use, for example, boost::filesystem, you'll have to build the binaries, as lib or shared object, and make sure it's available to the final executable shared binary search path.
You can find an explaination and more details in the boost documentation. Here is the linux version : http://www.boost.org/doc/libs/1_44_0/more/getting_started/unix-variants.html
From this page :
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.
...
The only Boost libraries that must be
built separately are:
Boost.Filesystem
Boost.GraphParallel
Boost.IOStreams
Boost.MPI
Boost.ProgramOptions
Boost.Python (see
the Boost.Python build documentation
before building and installing it)
Boost.Regex
Boost.Serialization
Boost.Signals
Boost.System
Boost.Thread
Boost.Wave
is /usr/lib in your LD_LIBRARY_PATH environment variable?