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
Related
I just wanted to understand how shared libraries with statically linked libraries are expected to perform. I am writing a shared library (lshared.so) that is statically linked to another library (lstatic). Now, I have another executable helloworld which loads a dynamic version of library lstatic (lstatic.so) and lshared.so as well. Will the static version of library (lstatic) loaded by lshared.so and the dynamic version (lstatic.so) conflict? Will they share any global state? Tried to show it better below.
helloworld
--> lshared.so (statically linked to lstatic at compile time)
--> lstatic.so (hello world loads this at runtime)
To throw some context, I've to use a shared library for logging. It is possible that lshared.so is statically linked to a different version that the one available to helloworld at runtime.
Will the static version of library (lstatic) loaded by lshared.so and the dynamic version (lstatic.so) conflict.
Possibly.
Will they share any global state.
Possibly.
The answers depend on how exactly lshared.so is built (which symbols it exports), and how the main helloworld binary is linked.
The answers also tend to be somewhat complicated, and may depend on inlining and other optimizations, and possibly on compiler versions.
It is best to avoid doing that by using shared version of lstatic.so, where all the answers become simple.
Let's say you compile a C++ shared library libBeta.so which makes use of pre-existing C++ shared libraries libAlpha1.so, libAlpha2.so, libAlpha3.so, etc. If I then write a C++ application which uses libBeta.so directly (and therefore indirectly uses the other libraries), should I link my application to libBeta.so only, or should I link my application to all libraries?
My intuition tells me that I should only link to libBeta.so, because linking to all libraries seems redundant as libBeta.so is already linked to the other libraries. However, undefined reference to errors are proving my intuition wrong.
Could someone explain me why my intuition might be wrong in particular cases?
p.s.:
OS: Linux
Compiler: g++
EDIT
As it turns out the tool I was using for compiling has different behaviour for compiling an executable and compiling a shared library. Linkage to sub-libraries were being omitted when compiling a shared library :(
Shared libraries are fully linked entities, and you don't need to explicitly link to their dependencies.
This is unlike static libraries which is only a collection of object files. When you use a static library you must link to its dependencies. But for share libraries, no you don't need that.
If you get undefined references, then it's not for the dependencies of the shared libraries you link to. It's either that you are missing linking with your own code, or you actually link with a static library.
You only need to link with your direct dependency, libBeta.so.
Actually, a few years ago on some Linux distributions you could get away with having indirect dependencies in your executable -- in this case, say, on libAlpha1.so -- and as long as the dependency gets loaded at runtime, directly or indirectly, the dependency would get satisfied.
This is no longer the case.
I am using OpenMP in my C++ code.
The libgomp.so.1 exists in my lib folder. I also added its path to the LD_LIBRARY_PATH
Still at run-time I get the error message: libgomp.so.1: cannot open shared object file
At Compile time I compile my code with -fopenmp option.
Any idea what can cause the problem?
Thanks
Use static linking for your program. In your case, that means using -fopenmp -static, and if necessary specifying the full paths to the relevant librt.a and libgomp.a libraries.
This solves your problem as static linking just packages all code necessary to run you program together with your binary. Therefore, your target system does not need to look up any dynamic libraries, it doesn't even matter if they are present on the target system.
Note that static linking is not a miracle cure. For your particular problem with the weird hardware emulator, it should be a good approach. In general, however, there are (at least) two downsides to static linking:
binary size. Imagine if you linked all your KDE programs statically, so you would essentially have hundreds of copies of all the KDE/QT libs on your system when you could have just one if you used shared libraries
update paths. Suppose that people find a security problem in a library x. With shared libraries, it's enough if you simply update the library once a patch is available. If all your applications were statically linked, you would have to wait for all of these developers to re-link and re-release their applications.
I am working on a project with SDL. I feel like a lot of my code could/should be reusable for any other projects I might want to take on.
I was going to start a library project, but I don't know how to go about linking to the SDL libraries.
Usually, I go to Project Settings and edited Mingw32 Linker to include the libraries (ming32, SDLmain, and SDL). But the linker does not show up in the settings.
So my questions:
Is there no linker settings because building a library is only a compiling operation?
And in general, is it possible to build a library on top of the existing libraries? That is, write my library using SDL functions and stucts. Or would I have to get the source code and rebuild entirely with my code included?
Also, advice on shared vs. static in this instance?
(Also, any advice for where to go about learning more about compilers and linkers and such. I got through data structures in school but no farther)
As an introduction, you have to distinguish very well static library from dynamic ones, they are completely different beasts... said that, to your questions:
Is there no linker settings because building a library is only a compiling operation?
I guess you are creating a static library in this case. A static library is simply the collection in one single object file of all the individual object files (i.e., the .o files produced by the compiler) that make up your source tree. No more, no less.
With a static library you don't need to specify which are the dependencies, since it is understood that it is when compiling the final executable that your library will be linked with all the other libraries that it depends upon. Therefore it is only at that time (final executable build) that any missing symbol will be detected, and all other libraries must be available.
A shared library (also dynamic library), is an executable file that embeds all the static libraries that it depends upon. It can also have external dependencies with other shared library, which would not be embedded.
And in general, is it possible to build a library on top of the existing libraries? That is, write my library using SDL functions and stucts. Or would I have to get the source code and rebuild entirely with my code included?
It is perfectly possible, both for static and dynamic libraries.
Also, advice on shared vs. static in this instance?
In this instance it is not possible to advice, because you don't specify enough information.
Look at this: When to use dynamic vs. static libraries, and this, to have a sort of guideline.
(Also, any advice for where to go about learning more about compilers and linkers and such. I got through data structures in school but no farther)
I think that the two links above give you plenty of information. If you want to further go into details, you could start from this wikipedia article and browse from there.
The library you are building can have external dependencies. That means that you can link it with SDL or any other external libraries that you like.
I think this page explains all your other questions: DLL Creation in MingW
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).