This is the mail archive of the
binutils@sourceware.org
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: drow at false dot org
- Cc: amodra at bigpond dot net dot au, binutils at sourceware dot org
- Date: Wed, 9 Aug 2006 13:35:36 -0700 (PDT)
- Subject: Re: weak defined symbols in shared object lost by dynamic link?
- Authentication-results: sj-dkim-1.cisco.com; header.From=sbalfour@cisco.com; dkim=pass ( sig from cisco.com verified; );
- Dkim-signature: a=rsa-sha1; q=dns; l=1806; t=1155155790; x=1156019790; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sbalfour@cisco.com; z=From:Stuart=20Balfour=20<sbalfour@cisco.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=j1+r2AdGDZXI+KAoZsUfvyVPm7Qu+PHSSTeqQj2/3JJFe//S7i5lggyLf4esrYlxa3rBD8zC 0KdyAZzkFT6aCu/Gk0rZOrRtzBbMb7yd3N9EkVoxIzcBw8gBLfdn+JP4;
Daniel,
I'm just catching up in HJ's thread. PROVIDE_HIDDEN might be the answer
going forward, but I'm reluctant to add feature content to binutils-2.14
or even binutils-2.15. I have three BFD ASSERTS and an application crash.
So I must answer the question, what did they (developers) do wrong, or
what do I (binutils maintainer) fix?
Make the argument that we must override weak defined and (possibly)
referenced symbols in shared objects with linker script PROVIDEd symbols.
PROVIDE is itself an escape mechanism (...don't forget these, but in case
you do, here they are... hope and pray). Can you give me an example of a
bad thing that happens? We made shared-object PROVIDEd symbols special,
with an attribute that's neither their binding nor visibility, so that we
tend to lose them along the way. That is a bit of complexity, because the
effect wouldn't happen if I had defined the symbols programatically in the
shared object. I'm groping here.
Stuart
>On Wed, Aug 09, 2006 at 10:37:39AM -0700, Stuart Balfour wrote:
>> 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.
>
>It sounds to me like what you need isn't another complex change in the
>dynamic symbol processing, but to use PROVIDE_HIDDEN in your shared
>library; that should force it to bind to the one you want.
>
>Here (and in HJ's ongoing thread) I think we're making some bad choices
>for complexity. We don't need to support every possible permutation of
>all the concepts we know how to deal with.
>
>--
>Daniel Jacobowitz
>CodeSourcery
>