Gold will not use indirect dependent shared libraries to resolve symbols in the main program whereas the old GNU linker will search indirect shared libraries to resolve such symbols. Using Ian's own words:
"If your program calls foo(), then you must explicitly link against some library which defines foo(). The GNU linker permits foo() to be defined indirectly, by a dependency of some shared library which you do explicitly link against. gold does not search those indirect dependencies for symbol definitions."
It is possible to detect this problem using the old GNU linker with by including the "--no-add-needed" flag to the linker (gcc -Wl,--no-add-needed). Note that --no-add-needed is a positional argument, so it is best to place it at the beginning of the GCC options. Here's an example from Roland:
==> foo1.c <==
#include <stdio.h>
extern int foo ();
int
main ()
{
printf ("%d\n", foo ());
}
==> foo2.c <==
extern int foo ();
int bar () { return foo (); }
==> foo3.c <==
int foo () { return 0; }
magilla 49 % gcc -g -fPIC -c foo1.c foo2.c foo3.c
magilla 50 % gcc -shared -o foo3.so foo3.o
magilla 51 % gcc -shared -o foo2.so foo2.o foo3.so
magilla 52 % gcc -o foo1 foo1.o foo2.so -Wl,--rpath-link=.
magilla 53 % gcc -Wl,--no-add-needed -o foo1 foo1.o foo2.so -Wl,--rpath-link=.
/usr/bin/ld: �: invalid DSO for symbol `foo' definition
./foo3.so: could not read symbols: Bad value
collect2: ld returned 1 exit status
[Exit 1]
For further discussion of this issue see http://sourceware.org/bugzilla/show_bug.cgi?id=10238
It had been reported in the past that the Linux kernel was broken if it was linked with Gold. That bug has been fixed (as of 11/3/2009).
glibc uses 'ld --verbose" to extract the default linker script which is then edited and used. Gold doesn't have a default linker script and thus the glibc build fails. Roland and Ian are discussing the reasons for this behavior from glibc.
Ian has mentioned that the PowerPC port is not currently functional.
Ian has mentioned that Google is working on an ARM port.