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

[Florian Weimer <fweimer@redhat.com>]

* 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.

Thanks,
Florian