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