[PATCH] Fix glibc 2.34 ABI omission (missing GLIBC_2.34 in dynamic loader)

[Florian Weimer]

* Florian Weimer via Libc-alpha:

> * Florian Weimer via Libc-alpha:
>
>> * Andreas Schwab:
>>
>>> On Dez 08 2021, Florian Weimer wrote:
>>>
>>>> * Andreas Schwab:
>>>>
>>>>> On Dez 08 2021, Florian Weimer via Libc-alpha wrote:
>>>>>
>>>>>> The glibc 2.34 release really should have added a GLIBC_2.34
>>>>>> symbol to the dynamic loader.
>>>>>
>>>>> Well, the ship has sailed.
>>>>
>>>> Has it?  It's just software, we can change it.
>>>
>>> ABI is not software, it's a contract.
>>
>> But sometimes we have to to fix bugs.  Again, what I propose is quite
>> different from a simple symbol change because distributions and users
>> can fix this now, well before the symbol is going to be used.
>>
>> I have considered using a stub DSO and mention that instead of libc.so.6
>> in the libc.so linker script.  But I'm not sure how we can prevent users
>> from linking against the moved symbol by bypassing the linker script.
>> That would produce ABI-incompatible binaries.  We could turn it into a
>> compat symbol, but as long as it's in the dynamic symbol table, some
>> people will use it.
>
> Let me propose a look at this from a different angle.
>
> Let's say we do not apply this change.  Then if we move dlopen (say)
> into ld.so, it needs to have a new symbol version, say dlopen@GLIBC_2.36
> (to enable early errors on old glibc even with lazy binding).  The net
> result will be that dlopen-using binaries linked against glibc 2.36 or
> later will not work with glibc 2.34.
>
> Binaries linked against glibc 2.34 with or without the proposed change
> are fully interoperable (forwards and backwards compatible).  No new
> symbol version/soname combination is ever generated by the link editor
> because the GLIBC_2.34 version in ld.so is effectively empty.
> Considering the moved dlopen, we would give it version of
> dlopen@GLIBC_2.34 (even if the symbol is added in glibc 2.36).  Binaries
> linked against glibc 2.36 will still fail when running at the initial
> version of glibc 2.34.  But with the proposed patch here, they will work
> even with glibc 2.34.  This means that there are no ABI
> incompatibilities introduce by this patch, and we enable compatibility
> with future symbol moves.

Andreas, do you find this line of reasoning convincing?

Thanks,
Florian