This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: GOLD LINKER DYNAMIC TABLE ISSUE
- From: Ian Lance Taylor <iant at google dot com>
- To: Takis Psarogiannakopoulos <takis at XFree86 dot Org>
- Cc: binutils at sourceware dot org
- Date: Fri, 11 Dec 2009 14:14:34 -0800
- Subject: Re: GOLD LINKER DYNAMIC TABLE ISSUE
- References: <20091211134839.X76977@public.xfree86.org>
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