GOLD LINKER DYNAMIC TABLE ISSUE

[Takis Psarogiannakopoulos]

There is an issue with the gold linker:

Format is ELF:

Suppose we have a libfoo.so which despite the .so extension is not really
a shared object but an archive that contains the real shared object.
Call it libfoo.so.1. Soname of this libfoo.so.1 is also libfoo.so.1
Also suppose that

objdump -T libfoo.so.1 is empty

When this happens the gnu linker 2.15 up to 2.20 will still link the
libfoo.so correctly creating an excutable that depends dynamically on
libfoo.so.1

However gold can not do that and it would directly complain that he cannt
find any symbols inside the libfoo.so.1 rejecting completely the link
command.

Ian Lance Taylor writes:

> It looks like the GNU linker uses the normal symbol table when there
> is no dynamic table, so that would have to be implemented in gold.

> As far as I can tell this can only work for a shared library embedded
> in an archive, where the real shared library used by the dynamic
> linker is elsewhere and is different.  The dynamic linker only looks
> at the dynamic symbol table, so it must be present at runtime.

> Ian

Ian, are you saying that the (such way) created executable from the GNU ld
is in anycase unusable because the dynamic liner would want in any case
to read the dynamic table of libfoo.so.1?
Cause this is certainly not the case

I have attached as a sample a couple of old files libc.so and libc.so.1 in
the tar archive to get an idea what I mean.
GNU ld will work fine with those two files and in fact the created exe
will dynamically depend on libc.so.1 and of course run just fine in the
native environment.

I have also opened a bug report

Regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ian.tar.gz
Type: application/x-gunzip
Size: 274682 bytes
Desc: 
URL: <https://sourceware.org/pipermail/binutils/attachments/20091211/d8d7480f/attachment.bin>