Re: A glibc dynamic linker or gld bug?

[Ian Lance Taylor <ian@zembu.com>]

   Date: Mon, 5 Jul 1999 20:48:14 -0700
   From: Richard Henderson <rth@twiddle.net>

   On Mon, Jul 05, 1999 at 02:55:51PM +1000, Geoff Keating wrote:
   > There is no way that a weak symbol defined in an
   > executable can be overriden by anything else, so there should be no
   > relocations referring to it.

   In the weak model prefered by glibc and SGI, sure there is.
   A strong symbol defined in a shared library will override 
   the weak symbol in the main executable.

   But this is not the model Sun prefers, since it kills their
   cute lazy loading scheme.

In order to implement ``strong defined symbol in shared library
overrides weak defined symbol in main executable'' correctly, we must
ensure that all relocations involving weak defined symbols in the
executable become dynamic relocations resolved at run time.

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.

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.

None of these choices seem clearly correct to me.

It is perhaps worth noting that the System V linker and the SGI
linker, unlike the GNU linker and the Solaris linker, considers a weak
definition followed by a strong definition to be a multiple definition
error.  (I am therefore a bit surprised to hear that the SGI dynamic
linker permits a strong definition in a shared library to override a
weak definition in an executable, since that appears to contradict the
program linker's behaviour.)

Ian