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

[Tobias Geerinckx-Rice <me@tobias.gr>]

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

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

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,

T G-R

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