This is the mail archive of the
mailing list for the binutils project.
Re: weak defined symbols in shared object lost by dynamic link?
- From: Stuart Balfour <sbalfour at cisco dot com>
- To: amodra at bigpond dot net dot au
- Cc: binutils at sourceware dot org
- Date: Wed, 9 Aug 2006 10:37:39 -0700 (PDT)
- Subject: Re: weak defined symbols in shared object lost by dynamic link?
- Authentication-results: sj-dkim-7.cisco.com; header.Fromemail@example.com; dkim=pass ( sig from cisco.com verified; );
- Dkim-signature: a=rsa-sha1; q=dns; l=1740; t=1155145114; x=1156009114; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; firstname.lastname@example.org; z=From:Stuart=20Balfour=20<email@example.com> |Subject:Re=3A=20weak=20defined=20symbols=20in=20shared=20object=20lost=20by=20dy namic=20link?; X=v=3Dcisco.com=3B=20h=3DCD9+3Ifvjp+dJG59lYNCubq+ZEs=3D; b=o5SrZe76NN5YYHV2OezW4T3v9x8l0TfP4GYzgICl098BpCWxDZTh7EqC5K6F2PFL82vD1hil CBiWBi4bmWLkL6ZPiiQuLRWQKEb/2mY4MD5qkwNVMO/653zo4RT2JU4I;
Note to Alan:
[I've looked over your patch for "ld/2218 fix for powerpc64" and while it
is related, it's not THIS problem]
>I think PROVIDE in a linker script ought to override all symbols defined
>in shared libs. At least, this is the most useful behaviour for symbols
>like "end" where the value in the shared library is not relevant in an
>IBM OzLabs - Linux Technology Centre
What's the definition of "not relevant"? In my case, the etext symbol in
the shared object is referenced by a routine in the shared object which
is called from the executable. It expects the value set for it in the
shared object's linker script.
I'd argue that the linker script is the court of last resort - after
everything is searched including shared objects and the executable has
undefined references, they're PROVIDED just to tidy things up, by the
linker script. If they're undefined by this point, maybe the PROVIDE'd
value doesn't matter... we may suppose that the program doesn't actually
use it. I guess.
So, elaborate your point that ignoring a defined AND used symbol from a
shared object is not a useful behavior. Can you buy the argument that
if the symbol is defined but NOT used that we override it in the
linker script? (It has to be a weak symbol, of course, because a strong
symbol will not be overridden by a linker script). Maybe this is the
crux of the matter. If it's *used* and resolved within the .so, it's
anchored. In my case, it actually was supplied by a linker script, sort
of as a default. But I could see where I might programmatically define
etext as weak, use it in a shared object, and lose it.