Fixing lib linkage for plugins/python extensions
On Mon, Nov 02, 2009, Sune Vuorela wrote:
> your app uses both libfoo and libbar. libbar uses libfoo. with ld, it
> is sufficient to do -lbar, and with gold you need -lfoo -lbar.
> in both cases, your app will have NEEDED entries for both libfoo and
If your app is using both libfoo and libbar, *do* link to both.
It seems the issues which gold catches are identical to the ld
--no-undefined / -z defs checks; these are usually due to bugs in the
build system not building intermediate objects with the proper link
flags (e.g. building foo.o without -lbar but building foo with an
object linked to libbar and hence outputting working binaries).
A tough case for not having resolvable symbols when outputting libs
at build time is plugins. For instance Gedit plugins
(/usr/lib/gedit-2/plugins/*.so) call into Gedit core functions without
being linked to a library providing the relevant symbols, but because
/usr/bin/gedit dlopens them, the symbols will be resolvable at runtime.
It gets worse when the symbols could possibly be resolved from
multiple binaries: libpython2.x.so versus /usr/bin/python2.x for
I'd love advice on the best way to resolve these last two cases;
perhaps there's a way to tell gold or ld about where the symbols will
be available at runtime, but not actually encoding a hard dependency on