public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Patrick Rother <krd@gulu.net>
To: libc-help@sourceware.org
Subject: installation of glibc crashes because of ABI sonames
Date: Mon, 26 Sep 2022 07:59:16 +0200	[thread overview]
Message-ID: <YzE/tNWQC2bhA6jH@vdr.gulu.net> (raw)

[-- Attachment #1: Type: text/plain, Size: 1599 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 155 bytes --]

             reply	other threads:[~2022-09-26  5:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-26  5:59 Patrick Rother [this message]
2022-09-26 11:35 ` Florian Weimer
2022-09-26 12:53   ` Patrick Rother
2022-09-26 12:57     ` Adhemerval Zanella Netto
2022-09-26 13:02       ` Florian Weimer
2022-09-26 13:11         ` Adhemerval Zanella Netto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YzE/tNWQC2bhA6jH@vdr.gulu.net \
    --to=krd@gulu.net \
    --cc=libc-help@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).