Ask Your Question

Revision history [back]

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

That means if libfoo.so depends on libbar.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_g and depends on libbar.so which defines symbols function_h and function_i. The program calls function_f and 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.

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

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

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

Example: libfoo.so libfoo.so defines symbol function_f and function_g function_f and function_gand depends on libbar.so libbar.so which defines symbols function_h and function_i. function_h and function_i. The program calls function_f and function_h function_fand function_h and just links against libfoo.so.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 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.