This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Documenting the (dynamic) linking rules for symbol versioning
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?
Cheers,
Michael
>>> to do if there is no default version. We currently do not perform a
>>> topological sort on the version graph to find the maximum version.
>>
>> My understanding is that the VERSYM section is set up in a chained
>> manner and the oldest and the newest can be derived from it.
>
> They are chained, but the specification does not tell us whether the
> version definition records are stored in a topologically sorted order in
> the file. We may have to re-sort them.
>
> Thanks,
> Florian
>
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/