This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Are the pthread "compatibility" copies of symbols in libc still necessary?
On Fri, Mar 16, 2018 at 1:38 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 03/16/2018 09:42 AM, Florian Weimer wrote:
>> On 03/16/2018 04:35 PM, Carlos O'Donell wrote:
>>>
>>> The specification says the data must be recorded, but it doesn't say what you
>>> have to *do* with the data?
>>
>> It does:
>>
>> “
>> A fatal error shall be triggered when no matching definition can be
>> found in the object whose name is the one referenced by the vn_name
>> element in the Elfxx_Verneed entry.
>> ”
>
> I don't know what drove this requirement.
>
> From a first-principles perspective is doesn't seem to derive from any
> foundational aspect of the linkage model.
I don't claim to know what Ulrich was thinking at the time, but if you
start from the premise that it would be more consistent in general if
symbols always resolved at load time to the library they were found in
at link time, then adding this requirement for versioned symbols can
be seen as a way to introduce that consistency in a
backward-compatible fashion. That said, without any way to declare
that symbol X is _supposed_ to have moved from foo.so to bar.so, it
puts us in a hole.
This is a GNU spec, so we _could_ change it. We'd need to do a bit of
formal consultation with everyone else who might be affected, but I
don't think our hands should be tied by a decision that nobody
remembers the original rationale for anymore.
zw