Re: Removing internal symbols

[Florian Weimer <fweimer at redhat dot com>]

* Adhemerval Zanella:

> On 27/01/2020 18:55, Samuel Thibault wrote:
>> Hello,
>> 
>> Expanding the subject a bit to catch more opinions on this:
>> 
>> Samuel Thibault, le mar. 21 janv. 2020 22:28:50 +0100, a ecrit:
>>> Adhemerval Zanella, le ven. 17 janv. 2020 17:40:09 -0300, a ecrit:
>>>>> diff --git a/sysdeps/mach/hurd/i386/libpthread.abilist b/sysdeps/mach/hurd/i386/libpthread.abilist
>>>>> index 0ede90859c..cda8755960 100644
>>>>> --- a/sysdeps/mach/hurd/i386/libpthread.abilist
>>>>> +++ b/sysdeps/mach/hurd/i386/libpthread.abilist
>>>>> @@ -14,8 +14,6 @@ GLIBC_2.12 _cthread_init_routine D 0x4
>>>>>  GLIBC_2.12 _cthreads_flockfile F
>>>>>  GLIBC_2.12 _cthreads_ftrylockfile F
>>>>>  GLIBC_2.12 _cthreads_funlockfile F
>>>>> -GLIBC_2.12 _pthread_mutex_destroy F
>>>>> -GLIBC_2.12 _pthread_mutex_init F
>>>>>  GLIBC_2.12 _pthread_mutex_lock F
>>>>>  GLIBC_2.12 _pthread_mutex_trylock F
>>>>>  GLIBC_2.12 _pthread_mutex_unlock F
>>>>
>>>> I understand this change is follow Linux internal implementation
>>>> and make mtx_init.c generic, but I don't think changing hurd 
>>>> libpthread exported symbols is the correct solution. 
>>>>
>>>> Since the symbol won't be used anymore I think we can move to
>>>> a compat symbol, something like:
>>>>
>>>> +strong_alias (__pthread_mutex_init, pthread_mutex_init);
>>>> +hidden_def (__pthread_mutex_init)
>>>> +#if SHLIB_COMPAT (libpthread, GLIBC_2_12, GLIBC_2_31)
>>>> +compat_symbol (libpthread, __pthread_mutex_init, _pthread_mutex_init, GLIBC_2_12);
>>>> +#endif
>>>
>>> But do we need to keep the compat symbols at all? 
>>>
>>> _pthread_mutex_lock has never been exposed in a .h file, it should have
>>> gotten version GLIBC_PRIVATE actually since it's only used between
>>> libc.so and libpthread.so.
>
> I think it might be fine in this case, assuming there is no external
> linkage possible with header redirection. It is still a ABI break, but
> if an application is using such symbol it is abusing the API.

I don't have any ABI tooling for Hurd.  But on GNU/Linux, GNU packages
often use internal APIs of other GNU packages, without much coordination
(probably assuming that's okay because it's all GNU).  For glibc, we try
to tell developers not to do that, but it's an ongoing effort and very
much incomplete at this point.

Thanks,
Florian