Contents
DSO Linking Changes for wheezy
Currently the linker uses indirect dependent shared libraries to resolve symbols when linking shared libraries or binaries. Not using indirect dependent shared libraries to resolve symbols has the disadvantage that indirectly linked shared libraries end up in the list of dependencies for a package. Effects of this change are:
- Binary packages will end up without dependencies on these indirectly linked shared libraries, reducing the number of dependencies for binary packages, making library transitions easier, reducing the amount of binNMUs needed for a library transition, and easing migration of packages to testing.
- Some packages will fail to build. Binaries, which are using symbols from an indirectly linked shared library will fail to link and need to be fixed to link with the shared library directly.
The issue
Some packages fail to build with ld.gold or ld.bfd --no-as-needed due to undefined reference. This is in most cases the problem that your executable links against a library A which links against library B, but your executable needs symbols in library B. This is problematic in the situation where library A removes its dependency to library B. The next time the executable gets rebuild it will break and cannot be linked.
This doesn't affect the created executable as it will still have entries in DT_NEEDED for both library A and library B in the case of an successful build. It isn't known which will be the preferred linker in the future or if the behavior will be changed in GNU ld or GNU gold.
All packages can be fixed by adding the needed library which provides the symbols to the linker call. In some cases the pkg-config file of library A could be broken as it requires library B for the build. This could be the case if the executable doesn't use library B directly in its source code, but library A inserts the symbols of library B using defines or other similar mechanisms inside their header files to executable, but hasn't the correct Requires statement inside the .pc file of library B.
A common problem seems to be calls to XOpenDisplay without directly linking to -lX11, but to a library like Xtst. Similar is to use glib2.0, but only linking to gtk2.0: using libm, but don't linking to it; libqt*, but only linking to kdecore. Another interesting problem is that some problem links there C++ object files using gcc instead of g++, but the g++ symbols gets resolved by another C++ library they link to.
Updated toolchain packages
Make sure that you install g++-4.5 and g++ (>= 4:4.5) from experimental. When only installing g++-4.5, but not changing the default GCC, make sure to build with CC=gcc-4.5 and CXX=g++-4.5.
Changes required for packages
The preferred way for the fix is to add the missing libraries to the link step to resolve the explicitely referenced symbols.
A workaround would be to link with -Wl,--as-needed -lfoo -Wl,--no-as-needed. Note that the --as-needed and --no-as-needed are positional parameters and the default behaviour should be restored after using this workaround.
Further information
- Builds failures (originally with ld.gold) are tracked in Debian:
- The Fedora Wiki offers information on a similiar change: