Ask Your Question
1

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++ boost_remove.cc -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/libboost_system.so.1.53.0 so try adding it to the linker command line
/lib64/libboost_system.so.1.53.0: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status

Sure enough this works:

$ g++ boost_remove.cc -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]);
  boost::filesystem::remove(filename);
  return 0;
}
edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
1

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/ld.gold which is an alternative implementation contained in binutils.

edit flag offensive delete link more
0

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 libfoo.so depends on ibbar.so and if the program just uses symbols defined in libfoo.so then the program just has to link against libfoo.so. The linker still transitively resolves the libbar.so then, as before.

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

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

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

Stats

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

Seen: 1,145 times

Last updated: May 11 '18