[prev in list] [next in list] [prev in thread] [next in thread]
List: glibc-alpha
Subject: Re: RFC: Don't output symbol version requirement for non-DT_NEEDED libs
From: "Carlos O'Donell" <carlos () redhat ! com>
Date: 2014-11-28 15:27:26
Message-ID: 5478945E.5010402 () redhat ! com
[Download RAW message or body]
On 11/27/2014 07:06 PM, Joseph Myers wrote:
> On Thu, 27 Nov 2014, Carlos O'Donell wrote:
>
>> On 11/27/2014 03:16 AM, Alan Modra wrote:
>>> So, absent someone implementing a glibc fix, how about we just drop
>>> the symbol versioning for weak symbols, when their defining library
>>> won't be in DT_NEEDED? Note that if "f" above was a strong symbol,
>>> ld will still complain with "./libb.so: error adding symbols: DSO
>>> missing from command line".
>>
>> This seems like the wrong thing to do, particularly since it violates
>> the principle of least surprise. I would expect the versioned symbol
>> to stay versioned.
>>
>> What's wrong with fixing this in glibc?
>
> Actually, I think it's a linker bug not a glibc bug. If you don't link
> with a library providing a symbol you use, I don't think any information
> at all about how it might be resolved with some library you didn't link
> against should be embedded in the binary: not a DT_NEEDED entry, and not a
> version requirement. I don't think you can presume at static link time,
> with a weak undefined symbol like that, "this symbol isn't needed, but if
> defined at runtime it must have this version" (as opposed to "this symbol
> isn't needed, and might have any version at runtime", which is the safe
> assumption).
I had not considered it like that. I agree with your rationale.
In which case this is clearly a bug in binutils and Alan's patch
is correct.
I tried to come up with a case where this would matter, but from
first principles I couldn't construct any sensible test cases.
Cheers,
Carlos.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic