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, theproblem 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 thatwhen one runs guix time-machine --commit=xxx -- environment pkgthe 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 oldglibc.
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
signature.asc
Description: PGP signature
