[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: " version `GLIBC_2.33' not found" with guix time-machine -

From: Tobias Geerinckx-Rice
Subject: Re: " version `GLIBC_2.33' not found" with guix time-machine --channels
Date: Sun, 09 Jan 2022 19:09:21 +0100

Hi Wiktor,

Regarding only

in an attempt to force removal of old store items in hope that they would be rebuilt and relinked to the new glibc. Unfortunately, the
problem persists.

which reveals a fundamental misunderstanding about Guix that could prevent you from grokking & fully enjoying it, which is why it's so important to correct.

I can't improve on Leo's excellent answer, but I can certainly repeat it, poorly, using different words!

Wiktor Żelazny 写道:
Thank you for your prompt reply. What about a situation where glibc is not an explicit package input? I suspect it is determined by the build system definition in such a (common) scenario. I further assume that
when one runs

   guix time-machine --commit=xxx -- environment pkg

the pkg definition corresponding to the Guix version xxx is used, but a
*current* Guix binary is used to execute the environment.

What you describe sounds less like Guix, than how the average source-based package manager works today: using whatever random components and GCC version it happens to find lying around on the host system at build time.

Guix package builds are completely self-contained, and specify their complete build environment (like a closure). This environment is in effect frozen in time and will never change.

‘guix time machine --commit=COMMIT -- COMMAND’ builds guix@COMMIT, and then everything to the right of the ‘--’ happens inside guix@COMMIT, i.e., ‘the past’. There is no link to the present.

There is no way for an old package built with time-machine to link to the new glibc because the new glibc didn't *exist* in ‘the past’, which is all the build ‘sees’. Assuming package P is bit-reproducible today, building it with guix time-machine in 25 years will produce a binarily-exact copy.

I’ve got this intuition that the current binary may assume the build system involving a new glibc, whereas the cached xxx version of pkg can be from the time when Guix defined a build system as using an old

Understandable intuition coming from other systems, but not valid for Guix.

Your kernel analogy is more accurate: somehow, once released from its functionally pure build environment, package P is being fed a glibc it was never compiled against.

There are many ways this could happen and there's (obviously) a bug here, which can be fixed, but rebuilding old packages in the hopes to change them is a complete waste of time.

Kind regards,


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]