This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: How should the GNU linker treat weak references?
- To: Mark Kettenis <kettenis at wins dot uva dot nl>
- Subject: Re: How should the GNU linker treat weak references?
- From: Ulrich Drepper <drepper at redhat dot com>
- Date: 02 Jul 2001 12:05:05 -0700
- Cc: binutils at sources dot redhat dot com, gcc at gcc dot gnu dot org
- References: <200107021825.f62IP6U12303@delius.kettenis.local>
- Reply-To: drepper at cygnus dot com (Ulrich Drepper)
Mark Kettenis <kettenis@wins.uva.nl> writes:
> Note that the Solaris linker doesn't suffer from this problem since it
> doesn't automagically add DT_NEEDED entries, and only includes DSO
> that are explicitly mentioned on the linker command line.
>
> Personally I think the Solaris behaviour is much saner, and I think
> that's what the GNU linker should do, at least by default.
Nope, but I also don't agree with the current behavior.
What should happen is that the linker recognizes that the undefined
reference comes from a DSO which was included by DT_NEEDED and in this
case it should not include a DT_NEEDED in the program itself.
This means the
a) the search path for the ld.so does not get disturbed by adding another
toplevel dependencies. Remember, the ld.so search path is breadth first.
b) if nothing changes in the DSOs etc the symbol is found just fine, just
the same way ld found it
c) but it also means if, for instance, the DSO with the initial DT_NEEDED
is changed and drops the DT_NEEDED the program won't run correctly.
But that's life. The author of the DSO changed its interface. S/He
should have used version maps to limit the exported symbols if this
is something which might come up in future.
The goal for ld must be to be as close to the ld.so behavior as
possible to reduce surprises and to not change the user's intentions
(see point a) above which is something which can truly be
catastrophic).
--
---------------. ,-. 1325 Chesapeake Terrace
Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
Red Hat `--' drepper at redhat.com `------------------------