[PATCH 1/3] nptl: Move pthread_sigmask implementation to libc

[Adhemerval Zanella]

On 13/03/2020 10:16, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>> On 13/03/2020 06:51, Florian Weimer wrote:
>>> * Adhemerval Zanella via Libc-alpha:
>>>
>>>> diff --git a/sysdeps/unix/sysv/linux/aarch64/libc.abilist b/sysdeps/unix/sysv/linux/aarch64/libc.abilist
>>>> index a4c31932cb..694efeb1e4 100644
>>>> --- a/sysdeps/unix/sysv/linux/aarch64/libc.abilist
>>>> +++ b/sysdeps/unix/sysv/linux/aarch64/libc.abilist
>>>> @@ -1447,6 +1447,7 @@ GLIBC_2.17 pthread_self F
>>>>  GLIBC_2.17 pthread_setcancelstate F
>>>>  GLIBC_2.17 pthread_setcanceltype F
>>>>  GLIBC_2.17 pthread_setschedparam F
>>>> +GLIBC_2.17 pthread_sigmask F
>>>>  GLIBC_2.17 ptrace F
>>>>  GLIBC_2.17 ptsname F
>>>>  GLIBC_2.17 ptsname_r F
>>>> diff --git a/sysdeps/unix/sysv/linux/aarch64/libpthread.abilist b/sysdeps/unix/sysv/linux/aarch64/libpthread.abilist
>>>> index d65beba958..48b368acb1 100644
>>>> --- a/sysdeps/unix/sysv/linux/aarch64/libpthread.abilist
>>>> +++ b/sysdeps/unix/sysv/linux/aarch64/libpthread.abilist
>>>> @@ -156,7 +156,6 @@ GLIBC_2.17 pthread_setconcurrency F
>>>>  GLIBC_2.17 pthread_setname_np F
>>>>  GLIBC_2.17 pthread_setschedprio F
>>>>  GLIBC_2.17 pthread_setspecific F
>>>> -GLIBC_2.17 pthread_sigmask F
>>>>  GLIBC_2.17 pthread_sigqueue F
>>>>  GLIBC_2.17 pthread_spin_destroy F
>>>>  GLIBC_2.17 pthread_spin_init F
>>>
>>> This change is not fully compatible: Newly-linked programs may incur
>>> lazy binding failures on older glibc versions because pthread_sigmask
>>> is not present in libc.so.6.
>>
>> But backward compatibility is not a fully support scenario. Do we
>> really need to handle such cases for the libpthread removal
>> project?
> 
> So far, our approach to symbol versioning has been that if the
> application (or DSO) loads, it will not fail later due to a missing
> symbol.  Some RPM-based distributions have no other mechanism to
> ensure correct package dependencies.

Yes, but my understanding was exactly that new loader behaviour
(f0b2132b3524) will prevent the failure for this specific case.
What I am getting is we are adding this constraint due a rpm
limitation, is that correct?