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