Re: A glibc dynamic linker or gld bug?

[Geoff Keating <geoffk@ozemail.com.au>]

> Date: 6 Jul 1999 22:10:30 -0400
> From: Ian Lance Taylor <ian@zembu.com>

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

There are also other cases that seem to go wrong at present.  For
instance, consider the case where an executable references a weak
symbol, but it is not defined anywhere.  Then, later, some shared
object defines it.  Usually, the address of the symbol (that is,
NULL), has been compiled into the executable in many places and no
relocs are/can be generated.

Or the converse; if the weak symbol is initially defined in a shared
object, referenced by the executable, but later becomes undefined.  I
think that if such a thing happens, it should be an error in ld.so
(only for symbols referenced by the executable, of course).  It would
be nice to make the first case a visible error too.

These cases are not fixable under the usual non-pic-executable model, in
which all addresses referenced by the executable are fixed at link
time.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>