Fixing lib linkage for plugins/python extensions

[Loïc Minier <lool@dooz.org>]

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
> libbar.

 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
 instance.

 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
 these binaries?

-- 
Loïc Minier