I have a project which uses the MongoDB C++ driver. As I'm on WinXP I have to use MongoDB 2.0, which uses Boost 1.42.
However my application uses Boost 1.48.
When I statically link the MongoDB driver and build my application I get a LNK1104 linker error that libboost_system-vc100-md-gd-1_42.lib is missing.
When I add this library in addition to the in the app required 1.48 library version, I get a LNK2005 "boost::system::throws already defined" linker error.
Is there a way to use Boost 1.42 in my static library for MongoDB and use Boost 1.48 in my application?
You could split your build process: first compile the MongDB C++ driver into a separate .lib while linking against Boost 1.42.0 Then in a second step you compile your own application, linking against the MongoDB library and Boost 1.48.0. This should work as long as the MongDB .lib does not expose any of the boost functions such as boost::system::throws. See this question for how to limit the public interface from exposing Boost symbols.
Alternatively, try compiling your entire application with only a single Boost version (either 1.42 or 1.48).
Related
I am writing a C++ application that has to read a binary .MAT file. So I need to use libmat and libmex to do this (note I am not using MEX files though). I am also trying to use boost::program_options to handle parsing command line arguments since this is a non-GUI application. I am using CMake to handle my build environment.
The version of boost we are working with is 1.59. However, when I try to link in program_options, CMake is finding the boost::program_options library in with the MATLAB libraries and the MATLAB libraries require boost 1.49. Then when I try to run the compiled application, it crashes because of using headers from 1.59 but the libraries from MATLAB's copies of 1.49. Does anybody have any ideas how I can use the two versions of boost since MATLAB will not work with 1.59 and MATLAB did not include the include files for 1.49.
If your application crashes, it means that sadly 1.49 and 1.59 are not binary compatible, so the only way this can work is that you force your application to use 1.59. There might be two options:
Force CMake to use 1.59 libraries, by setting BOOST_LIBRARYDIR variant to CMake.
Force CMake to use 1.59 libraries, and static versions of them, by additionally setting Boost_USE_STATIC_LIBS.
I don't actually use CMake, and FindBoost.cmake appears to not always be up-to-date, so I'm not 100% sure the static option will work, but give it a try.
The thing is, recently I installed a new version of boost on my ubuntu.. I had 1.46 and now I have 1.56. The problem I am facing is now some of the programs wont run since apparently they require:
error while loading shared libraries: libboost_program_options.so.1.46.1: cannot open shared object file: No such file or directory
is there a bypass around this. How to solve the problem ?
Boost versions are not binary compatible. That application needs boost-1.46.1 and it cannot use any other version.
Either install boost-1.46.1 or recompile and re-link your applications against the available boost version.
I have troubles with building boost libraries.
I am using version 1.55 on OS Win7.
According to documentation and another thread I found switches that work to build boost with zlib support.
I haven't found a way, how to build boost (static or dynamic) libraries with zlib being external dependency, and will be shipped with my application. In that way, any user can build/change his own zlib, as long as the interface is unchanged.
I such thing possible? Does boost support dynamic zlib linkage?
Finally, I was able to solve the problem with the following.
There is a bug in versions 1.55 and above. Building static libraries can be done using older jamfile (1.53).
For the dynamic library, you need to add zlib.cpp to your project and compile.
With dynamic, meaning there is only zlib.dll linked directly to your project.
I have a very basic client/server project that uses boost::asio. It generates two executables, a client and a server.
When I run the client, I get the following:
./client: error while loading shared libraries:
libboost_system.so.1.55.0: cannot open shared object
file: No such file or directory
This means that the program requires the boost_system binary to be loaded dynamically at run-time. This makes sense, as one dependency of boost_asio is boost_system.
What does this mean for the ease of distributing my application to end-users?
1) Do I simply pop my development version of the boost_system binary on my system, which in this case is libboost_system.so.1.55.0? How do I ensure that when the user runs the client, it will find the dynamic archive? Obviously, on my system, even with my boost install it still didn't find the archive.
2) I am building on Linux and thus I have .so binaries. How will #1 change if I try to cross-compile my app for Windows with mingw-w64?
I am brand-spanking new to distributing C++ programs and working with dynamic/shared libraries.
When I compile statically, I get the following warning:
Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
Suggestion:
1) If you use shared libraries, you'll definitely need to include those libraries your program actually uses alone with your executable.
2) Here is a list of the Boost libraries. Your program will require just a subset:
http://www.boost.org/doc/libs/1_49_0/more/getting_started/unix-variants.html
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
A few libraries have optional separately-compiled binaries:
Boost.DateTime has a binary component that is only needed if you're using its to_string/from_string or serialization features, or if you're targeting Visual C++ 6.x or Borland.
Boost.Graph also has a binary component that is only needed if you intend to parse GraphViz files. * Boost.Math has binary components for the TR1 and C99 cmath functions.
Boost.Random has a binary component which is only needed if you're using random_device.
Boost.Test can be used in “header-only” or “separately compiled” mode, although separate compilation is recommended for serious use.
Alternatively, you can link your program with static (.a) Boost libraries instead of shared (.so), in which case there will be NO runtime dependencies.
Or you can mix/match shared/statis as you wish.
The choice is yours.
Look at the Boost documentation: b2 Static and Shared libraries
As said, you need to compile boost with the static option, for example
bjam install --toolset=msvc variant=release link=static threading=multi runtime-link=static
You can have more information in this Thread
Do i have static or dynamic boost libraries?
Something to notice, if you do an ldd on your executable, you'll probably notice some runtime dependencies on gcc/libc libraries, even if you compile it in static mode.
That means your client platform has to have those libraries installed. 90% of the time they're there, but it might be more complicated when you compile with the latest version of the compiler and the client has an older one.
I've compiled a Linux package on ubuntu 12.04 which uses boost and on this system i have boost 1.46. I tried to run the compiled release on another system and it complains that it can't find libboost_system.so.1.46.1. That system has boost 1.49 installed. How do I compile so that the program uses whatever version of boot exists instead of the specific version on the development machine.
You cannot expect your program to work with a different version of the library.
The fact that there are /different/ versions implies that they're /not the same/.
As mentioned, either
statically link to your specific version, or
you can ship the shared libraries (as long as you put them in a app-specific location and make sure you find them at runtime). Incidentally, see the second example here: How to compile boost async_client.cpp for the relevant linker options to use a custom library (it assumes the same location is to be used at runtime (rpath)