Re: weak defined symbols in shared object lost by dynamic link?

[Alan Modra <amodra at bigpond dot net dot au>]

On Tue, Aug 08, 2006 at 06:24:37PM -0700, sbalfour@cisco.com wrote:
> is a shared object which defines and uses the symbols "etext", "edata" and
> "end".  They got to be defined by that shared object via a PROVIDE in the
> linker script used to produce the shared object.  They show up in the .so 
> dynamic symbol table as type "V" and have non-zero values.  In the linked 
> executable, these same symbols are again supplied by the default linker
> script, and they show up as type "A" with zero values.  The resulting 
> executable crashes because of it.

bfd_elf_record_link_assignment has had quite a few patches that fix a
particular problem people have found.  This problem you've found with
weak syms is another one.  :-(  I think the function needs some tidying
too, but let's get the semantics of PROVIDE clear first.

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