Re: A glibc dynamic linker or gld bug?

[hjl@lucon.org (H.J. Lu)]

> 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.