Documenting the (dynamic) linking rules for symbol versioning

Florian Weimer fweimer@redhat.com
Fri May 5 14:10:00 GMT 2017


On 04/20/2017 04:09 PM, Michael Kerrisk (man-pages) wrote:
> On 04/20/2017 03:45 PM, Florian Weimer wrote:
>> On 04/20/2017 03:15 PM, Siddhesh Poyarekar wrote:
>>> On Thursday 20 April 2017 06:31 PM, Florian Weimer wrote:
>>>>> Hmm interesting, I thought 'latest' would imply the last version in the
>>>>> sequence of versions in the map, but I guess it kinda makes sense that
>>>>> it is the @@ default, similar to how a static linker would pick it up.
>>>>
>>>> It might be another instance of bug 12977.  At least its fix will
>>>> involve preferring the default version in this case.  I don't know what
>>>
>>>   From Michael's test case it seems like it already is preferring the
>>> default version.  The fix would have to be to the comment that says
>>> prefer the oldest version for regular unversioned lookups and the
>>> *latest* for the dlsym lookups.
>>>
>>> That or I misunderstood what you said.
>>
>> I think it picked the default version by accident because of the way the
>> linker ordered the list.  But I could be mistaken.
> 
> How could I test your hypothesis? Just a longer chain of versions,
> maybe? Or oddly named version tags?

I'm no longer sure what I actually saw during testing.  May be the 
results also depend on the binutils version.  Based on source code 
inspection in glibc, I think there actually is a problem here, but I 
can't reproduce it with stock binaries.

Thanks,
Florian



More information about the Libc-alpha mailing list