weak defined symbols in shared object lost by dynamic link?

Stuart Balfour sbalfour@cisco.com
Wed Aug 9 17:57:00 GMT 2006


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]

Alan says:

>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
>executable.  Comments?
>
>-- 
>Alan Modra
>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.

			       Stuart



More information about the Binutils mailing list