This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: A glibc dynamic linker or gld bug?
- To: ian@zembu.com (Ian Lance Taylor)
- Subject: Re: A glibc dynamic linker or gld bug?
- From: hjl@lucon.org (H.J. Lu)
- Date: Tue, 6 Jul 1999 21:45:02 -0700 (PDT)
- Cc: rth@twiddle.net, geoffk@ozemail.com.au, hjl@lucon.org,drepper@cygnus.com, binutils@sourceware.cygnus.com,libc-hacker@sourceware.cygnus.com, jgg@ualberta.ca
> If we do not, then we will fail to implement the model correctly.
> Consider the case in which a main executable defines a symbol weakly,
> and a shared library does not define it at all. At present we will
> not generate any dynamic relocations for the weak defined symbol.
>
> However, if we later replace the shared library with one which does
> have a strong definition for the symbol, then correct operation would
> appear to require that that strong symbol override the weak symbol in
> the main executable.
>
> As far as I can see, this can only happen if all relocations involving
> the weak defined symbol are copied into the executable as dynamic
> relocations.
What if the definition in executable is strong? Do you have the same
problem? I don't think we should worry about this.
>
> Are we willing to pay that price for all weak defined symbols in all
> dynamically linked executables?
>
> Should we instead go for the half-measure of only copying relocations
> for weak defined symbols in the case where we link against a shared
> library which has a strong definition for the symbol? It's easy to
> predict that we will get bug reports on this in the future.
>
I have sent a patch to implement this.
H.J.