GOLD LINKER DYNAMIC TABLE ISSUE

[Ian Lance Taylor]

Takis Psarogiannakopoulos <takis@XFree86.Org> writes:

> 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 guess I wonder what file the dynamic linker finds at run time.
I assume that the dynamic linker does not actually open the archive
and find the shared object in there.  I assume that it instead finds a
different shared object, based on the DT_SONAME tag of the one in the
archive.  And I assume that the latter shared object has a dynamic
symbol table.

Note that how the dynamic linker works really affects gold.  When the
GNU linker sees a dynamic object with no dynamic symbol table, it
falls back on using the normal symbol table instead.  Gold will have
to do that as well.

Ian