From Fedora Project Wiki

Revision as of 16:37, 3 November 2009 by Jlaw (talk | contribs)

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 has been reported that glibc and the kernel do "strange" things to linker scripts and do not at the current time work with gold.

Ian has mentioned that the PowerPC port is not currently functional.

Ian has mentioned that Google is working on an ARM port.