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

[Florian Weimer <fweimer@redhat.com>]

* 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, what do you think?

Thanks,
Florian