installation of glibc crashes because of ABI sonames

[Patrick Rother]

Dear list members,

for an old system without package management I was used to update
glibc from the source, i.e. I downloaded the source, built it
accordingly and installed the new glibc by "make install".

As far as I understand, the new glibc will be copied to
/lib/libc-2.33.so, the new ld-linux is copied to /lib/ld-2.33.so,
etc. and ldconfig fixes all the symlinks and rebuilds /etc/ld.so.cache so
that the system switches to the new libs. Makes sense, works good.


This worked until glibc-2.33, but broke with 2.34, In the release
notes I find:

* Previously, glibc installed its various shared objects under versioned
  file names such as libc-2.33.so.  The ABI sonames (e.g., libc.so.6)
  were provided as symbolic links.  Starting with glibc 2.34, the shared
  objects are installed under their ABI sonames directly, without
  symbolic links.  This increases compatibility with distribution
  package managers that delete removed files late during the package
  upgrade or downgrade process.

Now the new glibc appears to be copied to /lib/libc.so.6 directly
within the "make install", and after that the install breaks by
segmentation fault and the whole system is unusable because there is
a new /lib/libc.so.6 but the rest is not yet installed.


So, before the quoted change is was possible to upgrade glibc from
source on a running system, but as of 2.34 this is no longer
possible.
Is there any chance to get the previous behaviour back as an option,
or is there any other way to install a glibc update from compiled
source on a running system?

Thank you very much, yours,
Patrick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-help/attachments/20220926/4980dc69/attachment.sig>