Gold does not seem to handle implicit shared library dependencies. The following test case fails: bar.c: ------ int bar() { return 0; } foo.c: ------ extern int bar(); int foo() { return bar(); } app.c: ------ extern int foo(); extern int bar(); int main(int argc, char *argv[]) { foo(); bar(); } Sequence of commands to reproduce: ---------------------------------- gcc -c -o app.o app.c gcc -fpic -c -o foo.o foo.c gcc -fpic -c -o bar.o bar.c ld -shared -olibbar.so bar.o ld -shared -olibfoo.so -L. -lbar foo.o gcc -o app -Wl,-rpath,. -L. -lfoo app.o Output: ------- /usr/bin/ld: app.o: in function main:app.c(.text+0x1f): undefined reference to 'bar' collect2: ld returned 1 exit status Reference: ---------- This example works perfectly with the old linker.
This is intentional. In order to implement this correctly, it's necessary for the linker to exactly emulate the dynamic linker. This is rather complicated on GNU/Linux; look at code like gld${EMULATION_NAME}_try_needed in src/ld/emultempl/elf32.em. Historically there have been many bugs in this code, and the effect has been both inappropriate errors and inappropriate non-errors. Also, searching for dependent shared libraries is very rarely useful, and it slows down the linker. I don't know of any reason why it is required, except for better error reporting in some cases (which is the reason that it was originally implemented in the GNU linker). While clearly this is a change in behaviour, I don't think it will affect very many programs. And the fix is simple: either link against the shared library which defines the symbol you need, or use the appropriate --unresolved-symbols option (here I have to admit that gold does not yet implement that option).