On 06/08/26 05:04, Andreas Schwab wrote:
> On Aug 05 2026, Florian Weimer wrote:
>
>> And therefore this breaks versioned dependencies in most RPM-based
>> distributions.
>
> This has nothing to do with RPM. It is an ABI break, and an object that
> references posix_spawn_file_actions_addchdir@GLIBC_2.44 will crash when
> run against libc.so from the glibc 2.44 release.
The idea is to readily backport to 2.44, but released 2.44 glibc won't be
able to run it correctly without the backport. It is not an ideal solution,
that's why I am not sure which breakage is more disruptive, the gnulib one
or the potential ABI break.
>
>>> Why not version 2.44.1 ? I guess the symbol versioning mechanism must
>>> support
>>> version numbers of the form <major>.<minor>.<subminor>, because in the past,
>>> some symbols were assigned to versions GLIBC_2.3.3 or GLIBC_2.3.4, for
>>> instance.
>>
>> We still have lots of old symbols like that. But we don't really know
>> how software reacts to new symbols of that structure.
>
> Names of version symbols are arbitrary, and are only chosen by
> convention. Nothing else depends on their particular format.
>
There is another issue with the current alias that I did not foresee: checking
on how to finish POSIX 2024, linking posix_spawn_file_actions_{addchdir,
addfchdir}
triggers linknamespaces issues (because it pulls the *_np alias).
So I think we will eventually need another symbol, either for 2.45 or
adding namespace clean one.
