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

[Florian Weimer <fweimer@redhat.com>]

* Siddhesh Poyarekar:

> On 12/8/21 15:16, Florian Weimer via Libc-alpha wrote:
>> The glibc 2.34 release really should have added a GLIBC_2.34
>> symbol to the dynamic loader. With it, we could move functions such
>> as dlopen or pthread_key_create that work on process-global state
>> into the dynamic loader (once we have fixed a longstanding issue
>> with static linking).  Without the GLIBC_2.34 symbol, yet another
>> new symbol version would be needed because old glibc will fail to
>> load binaries due to the missing symbol version in ld.so that newly
>> linked programs will require.
>> This needs to be backported to the glibc 2.34 release branch as
>> well,
>> where hopefully all distributions will pick it up eventually.
>
> ISTM we could move symbols between ld.so and libc.so at will, without
> bumping symbol versions because they'll always be used together.  In 
> that sense, maybe we should not really consider such moves as ABI
> events at all?

It's only possible to move symbols if version nodes exist on both
sides.  Therefore, this patch adds a version node to ld.so.

Without the version node, a binary linked against newer glibc will start
referencing GLIBC_2.34 in ld.so after a symbol move to ld.so.  The lazy
bindign consistency check for symbol version nodes in unpatch old glibc
2.34 will then reject to load such binaries, even though a symbol
definition would be found during binding (as you point out).

Thanks,
Florian