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

["Wiktor Żelazny" <wz@freeshell.de>]

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

On Sat, Jan 08, 2022 at 01:50:43PM -0500, Leo Famulari wrote:

> When you build a Guix package, its entire dependency graph including
> glibc (and all the way down to the bootstrap) is already specified.
> The dependencies are "set in stone" before you start building.

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

To use an analogy: let’s say that you’ve got a package definition which
does not change. But you upgrade the os kernel. There may be some change
in the kernel that will make the package behave differently despite the
same definition.

> Therefore, if you want to use a given package with a different version
> of glibc, you'll need to either 1) Use `guix pull` or `guix
> time-machine` to build that package with the desired glibc version or

guix time-machine is giving me the errors I listed. I’ve been running it
for months with the same commit in the channel specification and the
same manifest. That’s why I’m suspecting that some system-wide glibc
update is causing this issue. Or some update of the guix binary.

One more thing: the problem started after I had had to roll-back a
segfaulting guix build. This was a little bit messy process. After `guix
pull` using last working guix, `guix package -u` did almost nothing.
Only after another `guix pull` did it work as it should. Maybe this is
related, I don’t know.

> 2) Create a new package definition that depends on a different version
> of glibc.

What if there is no explicit glibc dependency in the current definition,
and so nothing that could be changed?

Am I missing something?

WŻ

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