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.
Related
I'm building a executable in a big project, one of its dependency, a .so file, is linked against boost 1.6.2, and the executable itself must be static linked to a different version of boost, I don't know the version of that, maybe 1.6.0, when I link to the .so directly, it's able to compile and link, but when I run that binary, the behaviour of that binary becomes strange when calling to the functions of classes of the external .so file, such as it can run into infinite lock, and core dump inside boost. But if I don't link a different version of boost, it works. I guess the version of boost caused this problem. Is that true? How can I fix this?
The safest thing to do is to rename the namespace of your statically linked version of boost to ensure there are no symbol clashes. Unfortunately I don't think boost has any macros for changing its namespace so you'll have to do a manual find and replace in the source code.
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.
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 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).
I am using the Boost headers in my project which is compiled by g++. I downloaded the Boost source and didn't build it so there are no library files to link.
When I read the Boost website (http://www.boost.org/doc/libs/1_40_0/) it says Boost.Thread requires its corresponding library, but I am happily using the <boost/thread/mutex.hpp>(boost::mutex) header without linking to the Boost thread library.
How do I really tell whether I need to link the corresponding library for using a particular Boost header file or not?
In a Terminal:
./bootstrap.sh --show-libraries
The output shows the list of libraries requiring special build and installation.
The Boost documentation states whether a given library is header only or not. If you're using a library which isn't specified header only, and are not linking against the corresponding library, it's undefined behavior.
The fact that it happens to work (or seems to work) isn't really relevant.