Re: Are the pthread "compatibility" copies of symbols in libc still necessary?

[Carlos O'Donell <carlos at redhat dot com>]

On 03/16/2018 12:13 PM, Zack Weinberg wrote:
> 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.

I agree. I'd like to investigate changing this, but don't see myself
having the time to do so in the next 4-6 months, not at least until
2.28 is out the door (I'm the RM).

Cheers,
Carlos.