Re: A glibc dynamic linker or gld bug?

[Richard Henderson <rth@twiddle.net>]

On Tue, Jul 06, 1999 at 10:10:30PM -0400, Ian Lance Taylor wrote:
> 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.

/* Should we do dynamic things to this symbol?  */

#define alpha_elf_dynamic_symbol_p(h, info)                             \
  ((((info)->shared && !(info)->symbolic)                               \
    || (((h)->elf_link_hash_flags                                       \
         & (ELF_LINK_HASH_DEF_DYNAMIC | ELF_LINK_HASH_REF_REGULAR))     \
        == (ELF_LINK_HASH_DEF_DYNAMIC | ELF_LINK_HASH_REF_REGULAR))     \
    || (h)->root.type == bfd_link_hash_undefweak                        \
    || (h)->root.type == bfd_link_hash_defweak)                         \
   && (h)->dynindx != -1)

This should probably just be generic.

> Are we willing to pay that price for all weak defined symbols in all
> dynamically linked executables?

I think so.  There are really very few of them in practice.
And failing to override weak symbols is surprising behaviour
from my point of view.

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

Really?  SGI does this?  I'm a bit surprised.

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

This based on how Uli reported that SGI was arguing the weak symbol
behaviour at load time topic at the IA64 ELF ABI meetings.  (Which,
btw, has reportedly degenerated into a generic ELF ABI meeting.)


r~