public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
* installation of glibc crashes because of ABI sonames
@ 2022-09-26  5:59 Patrick Rother
  2022-09-26 11:35 ` Florian Weimer
  0 siblings, 1 reply; 6+ messages in thread
From: Patrick Rother @ 2022-09-26  5:59 UTC (permalink / raw)
  To: libc-help

[-- 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 --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: installation of glibc crashes because of ABI sonames
  2022-09-26  5:59 installation of glibc crashes because of ABI sonames Patrick Rother
@ 2022-09-26 11:35 ` Florian Weimer
  2022-09-26 12:53   ` Patrick Rother
  0 siblings, 1 reply; 6+ messages in thread
From: Florian Weimer @ 2022-09-26 11:35 UTC (permalink / raw)
  To: Patrick Rother; +Cc: libc-help

* Patrick Rother:

> 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.

In my experience, it has always been required to use “make install
DESTDIR=…” to update a running system, and then move the resulting
temporary tree into place with a single command.  (The elimination of
symbolic links actually makes this step more reliable because there
are no older glibc .so files left behind.)  It never occurred to me
that we regressed this functionality because it didn't actually work
before for me.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: installation of glibc crashes because of ABI sonames
  2022-09-26 11:35 ` Florian Weimer
@ 2022-09-26 12:53   ` Patrick Rother
  2022-09-26 12:57     ` Adhemerval Zanella Netto
  0 siblings, 1 reply; 6+ messages in thread
From: Patrick Rother @ 2022-09-26 12:53 UTC (permalink / raw)
  To: Florian Weimer; +Cc: libc-help

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

Hello.

On Mon, Sep 26, 2022 at 01:35:46PM +0200, Florian Weimer wrote:
> > 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.
> 
> In my experience, it has always been required to use “make install
> DESTDIR=…” to update a running system, and then move the resulting
> temporary tree into place with a single command.  (The elimination of
> symbolic links actually makes this step more reliable because there
> are no older glibc .so files left behind.)  It never occurred to me
> that we regressed this functionality because it didn't actually work
> before for me.

I wasn't aware of the DESTDIR=… option, and interestingly that worked
like a charm.

Problem solved for me, thank you!


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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: installation of glibc crashes because of ABI sonames
  2022-09-26 12:53   ` Patrick Rother
@ 2022-09-26 12:57     ` Adhemerval Zanella Netto
  2022-09-26 13:02       ` Florian Weimer
  0 siblings, 1 reply; 6+ messages in thread
From: Adhemerval Zanella Netto @ 2022-09-26 12:57 UTC (permalink / raw)
  To: Patrick Rother, Florian Weimer; +Cc: libc-help



On 26/09/22 09:53, Patrick Rother wrote:
> Hello.
> 
> On Mon, Sep 26, 2022 at 01:35:46PM +0200, Florian Weimer wrote:
>>> 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.
>>
>> In my experience, it has always been required to use “make install
>> DESTDIR=…” to update a running system, and then move the resulting
>> temporary tree into place with a single command.  (The elimination of
>> symbolic links actually makes this step more reliable because there
>> are no older glibc .so files left behind.)  It never occurred to me
>> that we regressed this functionality because it didn't actually work
>> before for me.
> 
> I wasn't aware of the DESTDIR=… option, and interestingly that worked
> like a charm.
> 
> Problem solved for me, thank you!
> 

It is described on INSTALL file:

408 Installing the C Library
409 ========================
410
[...]
437    You can install the GNU C Library somewhere other than where you
438 configured it to go by setting the 'DESTDIR' GNU standard make variable
439 on the command line for 'make install'.  The value of this variable is
440 prepended to all the paths for installation.  This is useful when
441 setting up a chroot environment or preparing a binary distribution.  The
442 directory should be specified with an absolute file name.  Installing
443 with the 'prefix' and 'exec_prefix' GNU standard make variables set is
444 not supported.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: installation of glibc crashes because of ABI sonames
  2022-09-26 12:57     ` Adhemerval Zanella Netto
@ 2022-09-26 13:02       ` Florian Weimer
  2022-09-26 13:11         ` Adhemerval Zanella Netto
  0 siblings, 1 reply; 6+ messages in thread
From: Florian Weimer @ 2022-09-26 13:02 UTC (permalink / raw)
  To: Adhemerval Zanella Netto; +Cc: Patrick Rother, libc-help

* Adhemerval Zanella Netto:

> On 26/09/22 09:53, Patrick Rother wrote:
>> Hello.
>> 
>> On Mon, Sep 26, 2022 at 01:35:46PM +0200, Florian Weimer wrote:
>>>> 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.
>>>
>>> In my experience, it has always been required to use “make install
>>> DESTDIR=…” to update a running system, and then move the resulting
>>> temporary tree into place with a single command.  (The elimination of
>>> symbolic links actually makes this step more reliable because there
>>> are no older glibc .so files left behind.)  It never occurred to me
>>> that we regressed this functionality because it didn't actually work
>>> before for me.
>> 
>> I wasn't aware of the DESTDIR=… option, and interestingly that worked
>> like a charm.
>> 
>> Problem solved for me, thank you!
>> 
>
> It is described on INSTALL file:
>
> 408 Installing the C Library
> 409 ========================
> 410
> [...]
> 437    You can install the GNU C Library somewhere other than where you
> 438 configured it to go by setting the 'DESTDIR' GNU standard make variable
> 439 on the command line for 'make install'.  The value of this variable is
> 440 prepended to all the paths for installation.  This is useful when
> 441 setting up a chroot environment or preparing a binary distribution.  The
> 442 directory should be specified with an absolute file name.  Installing
> 443 with the 'prefix' and 'exec_prefix' GNU standard make variables set is
> 444 not supported.

We should probably error out in “make install” if DESTDIR is not set.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: installation of glibc crashes because of ABI sonames
  2022-09-26 13:02       ` Florian Weimer
@ 2022-09-26 13:11         ` Adhemerval Zanella Netto
  0 siblings, 0 replies; 6+ messages in thread
From: Adhemerval Zanella Netto @ 2022-09-26 13:11 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Patrick Rother, libc-help



On 26/09/22 10:02, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
>> On 26/09/22 09:53, Patrick Rother wrote:
>>> Hello.
>>>
>>> On Mon, Sep 26, 2022 at 01:35:46PM +0200, Florian Weimer wrote:
>>>>> 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.
>>>>
>>>> In my experience, it has always been required to use “make install
>>>> DESTDIR=…” to update a running system, and then move the resulting
>>>> temporary tree into place with a single command.  (The elimination of
>>>> symbolic links actually makes this step more reliable because there
>>>> are no older glibc .so files left behind.)  It never occurred to me
>>>> that we regressed this functionality because it didn't actually work
>>>> before for me.
>>>
>>> I wasn't aware of the DESTDIR=… option, and interestingly that worked
>>> like a charm.
>>>
>>> Problem solved for me, thank you!
>>>
>>
>> It is described on INSTALL file:
>>
>> 408 Installing the C Library
>> 409 ========================
>> 410
>> [...]
>> 437    You can install the GNU C Library somewhere other than where you
>> 438 configured it to go by setting the 'DESTDIR' GNU standard make variable
>> 439 on the command line for 'make install'.  The value of this variable is
>> 440 prepended to all the paths for installation.  This is useful when
>> 441 setting up a chroot environment or preparing a binary distribution.  The
>> 442 directory should be specified with an absolute file name.  Installing
>> 443 with the 'prefix' and 'exec_prefix' GNU standard make variables set is
>> 444 not supported.
> 
> We should probably error out in “make install” if DESTDIR is not set.

Agreed, not using DESTDIR is a potential source for trouble.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-09-26 13:11 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-26  5:59 installation of glibc crashes because of ABI sonames Patrick Rother
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

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).