Re: internal error in ld

[Alan Modra <alan at SPRI dot Levels dot UniSA dot Edu dot Au>]

I've already answered this privately with info about --no-whole-archive.
This is really just a copy for the binutils list, and has some more
details on the assertion failure.

On 14 Mar 2000, Marat Boshernitsan wrote:

> I am hitting an internal error in ld when I try to build a shared
> library with --whole-archive option:
> 
> /usr/misc/bin/g++ -shared  -fPIC  -ldl -L/usr/misc/lib -lgc \
> -Wl,-export-dynamic -Wl,--whole-archive -Wl,-soname,liblk.so -o \
> OBJ.x86-unknown-linux/liblk.so  util/OBJ.x86-unknown-linux/libutil.a \
> version/OBJ.x86-unknown-linux/libversion.a \
> node/OBJ.x86-unknown-linux/libnode.a \
> language/OBJ.x86-unknown-linux/liblanguage.a \
> grammar/OBJ.x86-unknown-linux/libgrammar.a \
> ilexer/OBJ.x86-unknown-linux/libilexer.a \
> iparser/OBJ.x86-unknown-linux/libiparser.a \
> tv/OBJ.x86-unknown-linux/libtv.a \
> ../common/OBJ.x86-unknown-linux/libcommon.a
> /usr/bin/ld: internal error ldlang.c 3757
> 
> This error appeared when I changed my compilation to use .a files and
> added --whole-archive option to the linker.  I first discovered this

The problem is that you need a --no-whole-archive after your library
files, otherwise ld tries to apply the --whole-archive processing to not
just your library files but also the ones g++ adds in.  Besides the fact
that this probably isn't what you intended, g++ will typically include
libgcc.a twice, leading to lots of multiple symbol definition errors.

The assertion failure is another problem, and seems to be an interaction
between --whole-archive and the way glibc works.  /usr/lib/libc.so is
actually a linker script with a GROUP command, and I'm guessing the GROUP
causes the problem, but I've run out of enthusiasm to debug this further.


Some details:
$ cat /usr/lib/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )

ldlang.c:load_symbols gets called with entry->filename = "c", then
next with entry->filename = "/lib/libc.so.6", then with 
entry->filename = "/usr/lib/libc_nonshared.a".

So far so good, but then for some reason we get another call with
entry->filename = "/usr/lib/libc_nonshared.a", and this one has
entry->the_bfd non-null, hence the assertion failure.