We use Boost statically linked with our app but now I want to use Boost Test with an external test runner and that requires the tests themselves to link dynamically with Boost.Test through the use of the required BOOST_TEST_DYN_LINK define.
Is this going to be a problem or is the way Boost Test links completely unrelated to the way the other Boost libraries are linked?
I believe Boost Test does not depend on any other compiled libraries, so dynamically linking it while statically linking the other Boost libraries should not be a problem. Our linking rules don't show any dependency of Boost Test on anything other than headers, nor do the rules in the boost.jam file (though the latter is out of date).
Related
I want to build a library which is easy to use and link to. Therefore, I do not want the user of my library to bother with building and linking against the libraries my library uses. What is the best approach of managing and building/linking the dependencies for your own library in order to assure the most simple usage of it?
E.g.: My library uses CURL and OpenSSL. Building and linking on Windows with those dependencies is a pain. I want to avoid this pain to the users of my library.
I use CMake for building.
Related to: Combine libraries and Linking static libraries to other static libraries
I'm working on a library that is statically linking our boost dependencies so that we do not have to worry about conflicting with users.
Our library statically links
date_time
system
thread
regex
filesystem
program options
We then have an executable that also needs program_options and links against it dynamically.
When we run the excutable we are getting a double free.
We could take the solution of not linking our code against program_options, which realistically we do not need to, but I want to know WHY this is happening and HOW to prevent it going forward.
Is the answer "don't link your library against boost statically"? If so then what kind of strategies exist to ensure that my boost and your boost play nice together? If the answer is "there are a few boost libraries which shouldn't be static" then is there a list?
I was able to address the double free issue by using GCC's -fvisibility=hidden when building boost.
For more information, see:
Static library loaded twice
https://lists.boost.org/boost-users/2015/01/83575.php
I'm using the ASIO libraries to make a udp sending wrapper. The intent is for this to be used by another app to easily send 3 specific udp messages.
I've created a .lib file which is basically an exported utility class that wraps the ASIO functions.
To test my lib I also made a little command line app which links to my lib, creates the exported class and calls the send function.
However, the test application is requiring to link to libboost_system-vc100-mt-gd-1_55.lib but the lib file I created which actually contains the Boost code does not.
Why is this happening and how can I fix this?
A .lib file, static library, is just a grouping of object files, it's not an executable entity. It isn't linked thus it doesn't require it's unresolved symbols to be resolved.
Only the executable or shared library (DLL) that link with it need the dependencies (in this case your test code).
So there's no problem, perhaps you meant to bundle your library as a shared library rather than a static library?
Most of the boost libraries rely on boost::system because of the exception/error management is used.
boost::asio definitely uses that.
A test runner application needs to link everything as it's going to be a (statically or dynamically linked) executable, and all of the references need to be resolved.
The Boost::Asio library is available (from the same author) as a header-only standalone version.
See his think-async.com website for details, and comparison. The standalone version is useful when you do not need (or want) to have a link-time depedency on Boost. More details are on the AsioStandalone page.
FWIW I bundled this for use by R programmers as CRAN package AsioHeaders because the 'no linking' feature makes the cross-platform use particularly appealing.
You could similarly provide header-only solution for your application.
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'm developing a small ATL DLL file in Windows/Visual Studio IDE, and I'm relatively new to C++/Boost. I've added the Boost library directory under the Linker options, and added the Boost root directory as an additional include directory. In my code I'm adding it like:
#include <boost/algorithm/string.hpp>
Will this be statically linked, dynamically linked, or not linked at all?
Will this be statically linked, dynamically linked, or not linked at all?
The answer is "It depends".
Boost is big. To steal a line from Douglas Adams, Boost "is big. Really big. You just won't believe how vastly, hugely, mindbogglingly big it is."
Some parts of Boost are implemented purely as templates: There are no calls to functions that were previously compiled and stored in some library. Use just these parts of Boost and there is no need for the Boost library.
Other parts of Boost do call functions that were previously compiled and stored in some library. These will need to be linked in. Whether that is done dynamically or statically depends on (a) whether you (or some sysadmin) built the Boost library as a dynamic vs. static library, and (b) how you (or your makefile) tells the linker to treat the Boost library.
Including any headers will embed that code in your source files for compilation.
So the code will be linked, as all your symbols will be, but it's not separately linked.