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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
