Ask Your Question

How to enable old transitive DSO link behaviour?

asked 2013-12-09 11:38:22 -0500

gsauthof gravatar image

updated 2018-05-11 14:39:35 -0500

Looking at Understannding DSO Link Change I understand that (by default) the linker (ld) does not transitively resolves shared library dependencies.

For example for a simple program that calls a function from boost_filesystem and you link like this:

$ g++ -lboost_filesystem

Then you get something like:

/usr/bin/ld: /tmp/ccxkAkLn.o: undefined reference to symbol '_ZN5boost6system15system_categoryEv'
/usr/bin/ld: note: '_ZN5boost6system15system_categoryEv' is defined in DSO /lib64/ so try adding it to the linker command line
/lib64/ could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

Sure enough this works:

$ g++ -lboost_system -lboost_filesystem

Is there a way to get the old behaviour on Fedora?

(the old behaviour where the linker automatically (i.e. transitively) resolves all shared library dependencies such that just specifying -lboost_filesystem is perfectly fine)

example source:

#include <boost/filesystem.hpp>
#include <string>
using namespace std;
int main(int argc, char **argv)
  string filename(argv[1]);
  return 0;
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted

answered 2013-12-11 08:51:45 -0500

Nils Philippsen gravatar image

Not that I think that this is a good idea, but you might try your luck with the --copy-dt-needed-entries option to ld or if that fails /usr/bin/ which is an alternative implementation contained in binutils.

edit flag offensive delete link more

answered 2018-05-11 14:37:40 -0500

gsauthof gravatar image

updated 2018-05-11 14:42:21 -0500

With the DSO-Link-Change the linker still transitively resolves dependencies of shared libraries.

That means if depends on and if the program just uses symbols defined in then the program just has to link against The linker still transitively resolves the then, as before.

What changed is something different: if the program also uses a symbol defined in it always has to explicitly link against even if it already links against another library (like that depends on as well.

Example: defines symbol function_f and function_gand depends on which defines symbols function_h and function_i. The program calls function_fand function_h and just links against

Link behavior before the DSO-Link-Change: the program can be successfully linked.

Link behavior after the DSO-Link-Change: the linking fails with an error message similar to the one quoted in the question (... undefined reference to function_h ...).

Clearly, the DSO-Link-Change improves the robustness and portability of C/C++ programs developed under Fedora. As dependencies of libraries may change, this behavior guarantees that no implicit dependency is overlooked before. Similarly, other systems might be already more strict regarding implicit/indirect library dependencies and/or other systems have other library versions compiled with other features and thus linked against a different set of dependent libraries.

Since Boost is a big C++ library collection with many interconnected modules and some template magic it isn't necessarily immediately obvious which additional symbols from another shared library a simple function call adds to program binary.

edit flag offensive delete link more

Question Tools

1 follower


Asked: 2013-12-09 11:38:22 -0500

Seen: 1,151 times

Last updated: May 11 '18