Re: [PATCH] Revert "Detect ld.so and libc.so version inconsistency during startup"

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 25/08/22 11:44, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 25/08/22 11:17, Florian Weimer wrote:
>>> * Adhemerval Zanella Netto:
>>>
>>>> On 25/08/22 03:03, Florian Weimer via Libc-alpha wrote:
>>>>> This reverts commit 6f85dbf102ad7982409ba0fe96886caeb6389fef.
>>>>>
>>>>> Once this change hits the release branches, it will require relinking
>>>>> of all statically linked applications before static dlopen works
>>>>> again, for the majority of updates on release branches: The NEWS file
>>>>> is regularly updated with bug references, so the __libc_early_init
>>>>> suffix changes, and static dlopen cannot find the function anymore.
>>>>>
>>>>> While this ABI check is still technically correct (we do require
>>>>> rebuilding & relinking after glibc updates to keep static dlopen
>>>>> working), it is too drastic for stable release branches.
>>>>
>>>> Sounds reasonable, although this is a configure options not enabled by
>>>> default.  Maybe extend the notes on either documentation and release wiki
>>>> to describe the pitfalls of this option?
>>>
>>> The hash suffix is always active, even without the configure option.  So
>>> no, we can't leave this in as an optional feature.
>>>
>>
>> Can't we make it optional then iff the configure option is enable to a
>> version different than an empty one? Basically making the default as is
>> and if user adds --with-extra-version-id= to use the new scheme? 
>>
>> I will change the GLIBC_PRIVATE abi, but I think it should be expected.
> 
> Is anyone going to use this?  The static dlopen breakage would be pretty
> drastic.  And we just found out that this commit (which has been
> backported widely, I think)
> 
> commit 2376944b9e5c0364b9fb473e4d8dabca31b57167
> Author: Stefan Liebler <stli@linux.ibm.com>
> Date:   Wed Apr 13 14:36:09 2022 +0200
> 
>     S390: Add new s390 platform z16.
>     
>     The new IBM z16 is added to platform string array.
>     The macro _DL_PLATFORMS_COUNT is incremented.
>     
>     _dl_hwcaps_subdir is extended by "z16" if HWCAP_S390_VXRS_PDE2
>     is set. HWCAP_S390_NNPA is not tested in _dl_hwcaps_subdirs_active
>     as those instructions may be replaced or removed in future.
>     
>     tst-glibc-hwcaps.c is extended in order to test z16 via new marker5.
>     
>     A fatal glibc error is dumped if glibc was build with architecture
>     level set for z16, but run on an older machine. (See dl-hwcap-check.h)
> 
> breaks the GLIBC_PRIVATE ABI, and it is not even detected by the hashing
> I implemented.  So I think the trade-offs for the hashing/fingerprinting
> implemented in the way the existing commit does are just very bad: it
> breaks many totally harmless updates, and does not even reliably detect
> the problematic updates.

Fair enough, I agree that breaking static dlopen sounds a big change.