Overlinking issues in packaging

From Wiki [en] OpenMandriva
Jump to: navigation, search


What is overlinking

example: when emacs build with libpng support, it uses -lz in case we're linking with a static PNG library. Alas this is bad when doing dynamic linking: if we update zlib to a new major version, emacs will have to be rebuilt, even if emacs doesn't use it all, only libpng does.

How to detect

Check a binary

Use "ldd -u -r", example:

% ldd -u -r /usr/bin/emacs
Unused direct dependencies:

When building a package

You will get a warning as explained here (the check is done by strip_and_check_elf_files from spec-helper)

How to fix

pkgconfig issues

Some software uses $(pkg-config --libs somefoo) to get the needed linker flags. Pkg-config uses the "Libs:" and "Requires:" entry from *.pc file to get the linker flags.

However, many *.pc files incorrectly specify their own dependencies in "Libs:" or "Requires:" while their own dependencies should be in "Libs.private:" and "Requires.private:".[1]

Example from gtk+-2.0.pc:

Requires: gdk-${target}-2.0 atk cairo

whereas it should be:

Requires.private: gdk-${target}-2.0 atk cairo

Example from libavcodec.pc from ffmpeg:

Libs: -L${libdir} -lavcodec -lz -pthread -lm -la52 -lfaac -lfaad -lmp3lame -lm -lnut -ltheora -logg -lvorbisenc -lvorbis -logg -lx264 -lm -lxvidcore    -ldl -ldl -lX11 -lXext

whereas it should be:

Libs.private: -lz -pthread -lm -la52 -lfaac -lfaad -lmp3lame -lm -lnut -ltheora -logg -lvorbisenc -lvorbis -logg -lx264 -lm -lxvidcore    -ldl -ldl -lX11 -lXext
Libs: -L${libdir} -lavcodec
  1. they are historical reasons for this: Requires.private and Libs.private were not existing in early pkgconfig (before 0.18) and were not backward compatible.

libtool issues

Libtool archives (*.la) contain a list of the used libraries, recursively. Default libtool specificies all those libraries explicitly, even for dynamic linking. This is fixed using a patch from debian.

However, usually software bundles their own libtool. One way to update it is to run "autoreconf" before configure. But it sometimes fail, so Mandriva has a script "fix-libtool-overlinking" called in %configure and %configure2_5x

See also : libtool archives

various issues

Alas fixing libtool and *.pc files is not enough:

  • xdm is built with -lXinerama whereas it doesn't need it, only /usr/lib/X11/xdm/authdir needs it. But to simplify the Makefile, the same LDFLAGS is used.
  • emacs is wrongly built with -lz, just in case emacs is built statically. The configure.in of emacs would need to fixed.

The best way to fix those issues is to fix them and report the fix upstream.


It can be hard and time consuming to correctly fix and report upstream. An easier way to fix is to use --as-needed. A global --as-needed is used in Mandriva since May 2008

Problems introduced by --as-needed

Underlinked library

Problems introduced by --as-needed can come from an underlinked library.

Do not use [me@mandrivapc]$ %define _disable_ld_as_needed 1 to workaround this, or only temporarily. Fix the library instead! (hint: fedora has already done patches to fix those issues, back in 2003 when they introduced prelink)

Wrong linking order

gcc -Wl,--as-needed -lfoo bar.o

is wrong, since ld will look for the symbols missing only in the files coming after it. So [me@mandrivapc]$ -lfoo will be simply ignored when using --as-needed.

You must ensure the libraries are put after *.o files:

gcc -Wl,--as-needed bar.o -lfoo

It usually happens when libraries are fed into LDFLAGS (which is incorrect)

See Gentoo's really nice page about --as--needed for more explanations.

Same symbol is different libraries

See segfault using pcre and --as-needed