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

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

[Wiktor Żelazny]

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

Dear Guix,

I’ve been having a problem illustrated by this MWE for the last couple
of weeks:

   $ guix time-machine --channels=channel-specs.scm -- environment bash
   /gnu/store/bb27inmp90vyx59q1453zl1rs9h73kjd-guile-wrapper/bin/guile: /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/3lsrx30nl5cacva8a8rd2xy08xlszx14-libx11-1.7.2/lib/libX11.so.6)
   /gnu/store/bb27inmp90vyx59q1453zl1rs9h73kjd-guile-wrapper/bin/guile: /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/2sgw9si0va897m6mvgwmv9ilx6szqxc8-libxau-1.0.9/lib/libXau.so.6)
   /gnu/store/bb27inmp90vyx59q1453zl1rs9h73kjd-guile-wrapper/bin/guile: /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/libc.so.6: version `GLIBC_2.33' not found (required by /gnu/store/7x63qm1byi8j72rd4nkv01nbpqvrr80s-libbsd-0.10.0/lib/libbsd.so.0)

   $ cat channel-specs.scm
   (list (channel
           (name 'guix)
           (url "https://git.savannah.gnu.org/git/guix.git")
           (commit
             "82344f59363530a092f4bbaca809820b2077b5fe")))

The commit is from March 2021.

Guessing that this has something to do with glibc system-wide version
upgrade (no idea, why X libraries are involved here, though), I tried:

   guix pull --delete-generations=1m
   sudo guix system delete-generations 1m
   guix gc --delete-generations=1m

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. Maybe I should use a shorter period than one month. I
also tried adding glibc@2.31 and glibc@2.33 to the environment as well
as replacing the commit with its direct descendant
3095255b7bdb194479dbc58d6d51dff752b3352f.

   $ guix describe
   Generation 156  Jan 06 2022 12:39:07    (current)
     guix 5d2b8b0
       repository URL: https://git.savannah.gnu.org/git/guix.git
       branch: master
       commit: 5d2b8b0ee31d0d9dccb880d393da29a09e1a9352
     guix-wz 4b30612
       repository URL: file:///home/w/guix/guix-wz-git
       branch: master
       commit: 4b30612d94261b5786d8c58cadd58fc4804ca148

   $ guix system describe
   Generation 100  Jan 06 2022 13:15:28    (current)
     file name: /var/guix/profiles/system-100-link
     canonical file name: /gnu/store/43chbfkyqy6mqh0ahv4ds7nwyd7wg47k-system
     label: GNU with Linux-Libre 5.15.13
     bootloader: grub
     root device: /dev/mapper/container
     kernel: /gnu/store/srpn65k9wkz9jzksxlgqyzzvdwzlkak0-linux-libre-5.15.13/bzImage
     channels:
       guix-wz:
         repository URL: file:///home/w/guix/guix-wz-git
         branch: master
         commit: 4b30612d94261b5786d8c58cadd58fc4804ca148
       guix:
         repository URL: https://git.savannah.gnu.org/git/guix.git
         branch: master
         commit: 5d2b8b0ee31d0d9dccb880d393da29a09e1a9352
     configuration file: /gnu/store/1vgycmrcrahs2vvkx73g2ng0bdlpdagf-configuration.scm

There is no fancy low-level stuff in my private channel.

What is the cause of this? Any solution? Not sure if I should file a bug
report or it’s just me not understanding some Guix quirk.

Thank you in advance,

WŻ

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

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

[Leo Famulari]

On Sat, Jan 08, 2022 at 04:11:55PM +0100, Wiktor Żelazny wrote:
> Guessing that this has something to do with glibc system-wide version
> upgrade (no idea, why X libraries are involved here, though), I tried:
> 
>    guix pull --delete-generations=1m
>    sudo guix system delete-generations 1m
>    guix gc --delete-generations=1m
> 
> in an attempt to force removal of old store items in hope that they
> would be rebuilt and relinked to the new glibc.

A point of clarification on this subject:

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. You can
rebuild the package as many times as you want, but its dependencies will
never change.

When I say the dependency graph is already specified, I am referring to
all the package definitions found in our Git repo. Whenever you use
Guix, you are using a particular revision ("commit") of the Git repo.
You can check which revision is currently effective with the `guix
describe` command:

For example:

------
$ guix describe
Generation 184	Jan 02 2022 13:19:48	(current)
  guix dfc5d52
    repository URL: https://git.savannah.gnu.org/git/guix.git
    commit: dfc5d5247f0e3d355c25484ea3d95ba2a6077895
------

So, any time I use Guix to build or install a package, it will do so
based on the package definitions found at commit dfc5d5247f0 in our Git
repo — no matter what you do, the dependencies will not change until you
run `guix pull` or use `guix time-machine`.

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
2) Create a new package definition that depends on a different version
of glibc.

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

[Wiktor Żelazny]

[-- 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 --]

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

[Ricardo Wurmus]

Wiktor Żelazny <wz@freeshell.de> writes:

> One more thing: the problem started after I had had to roll-back a
> segfaulting guix build.

Guix should not segfault.  A segfault is always a severe bug.  Or it’s
an indication that LD_LIBRARY_PATH is set, forcing incompatible
libraries to be used.

Is LD_LIBRARY_PATH set?  Do you have glibc installed in your default
profile?

-- 
Ricardo

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

[Wiktor Żelazny]

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

On Sun, Jan 09, 2022 at 07:03:33PM +0100, Ricardo Wurmus wrote:
>
> Wiktor Żelazny <wz@freeshell.de> writes:
>
> > One more thing: the problem started after I had had to roll-back a
> > segfaulting guix build.
>
> Is LD_LIBRARY_PATH set

Not anymore.

   $ set | grep LD_LIBRARY_PATH
   [nothing]

> Do you have glibc installed in your default profile?

Nope.

   $ guix package --list-installed | grep glibc
   [nothing]

I’ve got glibc-locales in /etc/config.scm.

WŻ

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

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

[Wiktor Żelazny]

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

On Sun, Jan 09, 2022 at 07:49:30PM +0100, Wiktor Żelazny wrote:
> On Sun, Jan 09, 2022 at 07:03:33PM +0100, Ricardo Wurmus wrote:
> >
> > Wiktor Żelazny <wz@freeshell.de> writes:
> >
> > > One more thing: the problem started after I had had to roll-back a
> > > segfaulting guix build.
> >
> > Is LD_LIBRARY_PATH set
>
> Not anymore.

Still, this looks like some interference from the environment. When I
ran `su $username` first, there was no error. I ran `set` before and
after `su` and diffed the results. The only suspicious thing I found
was:

   --- nosuset   2022-02-03 14:46:16.691231539 +0100
   +++ suset     2022-02-03 14:45:51.658607639 +0100

   -LD_PRELOAD=/gnu/store/s53sv4740vkaqzn3m2zvvnpy26hg2925-spectrwm-wz-3.2.0/lib/libswmhack.so.0.0

It’s related to the window manager, which is related to Xorg, and the
LIBC error pertains to X libraries. Could there be a connection here?

Sure enough, unsetting LD_PRELOAD seems to fix things, too.

From spectrwm man page:

   Note that workspace mapping is handled via libswmhack.so. When
   autorun spawns windows via a daemon, ensure the daemon is started
   with the correct LD_PRELOAD in its environment.

   For example, starting urxvtd(1) via xinit(1):

   LD_PRELOAD=/usr/lib/libswmhack.so.0.0 urxvtd -q -o -f

   Spawned programs automatically have LD_PRELOAD set when executed.

I guess I need to alias guix to "unset LD_PRELOAD; guix" until I find
some more elegant solution.

WŻ

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

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

[André A. Gomes]

Ricardo Wurmus <rekado@elephly.net> writes:

> Wiktor Żelazny <wz@freeshell.de> writes:
>
>> One more thing: the problem started after I had had to roll-back a
>> segfaulting guix build.
>
> Guix should not segfault.  A segfault is always a severe bug.  Or it’s
> an indication that LD_LIBRARY_PATH is set, forcing incompatible
> libraries to be used.
>
> Is LD_LIBRARY_PATH set?  Do you have glibc installed in your default
> profile?

Could you please explain me why having glicb in the default profile is a
bad idea?  I installed it so that I could read the docs from the comfort
of the info program.

My question follows from the fact that I observe the following message
lately.  It also reminds me that I should pack QMK for guix.

--8<---------------cut here---------------start------------->8---
Warning: Could not import qmk.cli.console: ImportError, Unable to load
any of the following libraries:libhidapi-hidraw.so libhidapi-hidraw.so.0
libhidapi-libusb.so libhidapi-libusb.so.0 libhidapi-iohidmanager.so
libhidapi-iohidmanager.so.0 libhidapi.dylib hidapi.dll libhidapi-0.dll
--8<---------------cut here---------------end--------------->8---

Thanks.


--
André A. Gomes
"Free Thought, Free World"

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

[Ricardo Wurmus]

André A. Gomes <andremegafone@gmail.com> writes:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Wiktor Żelazny <wz@freeshell.de> writes:
>>
>>> One more thing: the problem started after I had had to roll-back a
>>> segfaulting guix build.
>>
>> Guix should not segfault.  A segfault is always a severe bug.  Or it’s
>> an indication that LD_LIBRARY_PATH is set, forcing incompatible
>> libraries to be used.
>>
>> Is LD_LIBRARY_PATH set?  Do you have glibc installed in your default
>> profile?
>
> Could you please explain me why having glicb in the default profile is a
> bad idea?

It’s not a bad idea in general, but in combination with other
environment variables it might be.  I’m just trying to get a little more
information on what the problem might be.

-- 
Ricardo

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

[Tobias Geerinckx-Rice]

[-- 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 --]

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

[Wiktor Żelazny]

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

On Sun, Jan 09, 2022 at 07:09:21PM +0100, Tobias Geerinckx-Rice wrote:

> that could prevent you from grokking & fully enjoying it, which is why
> it's so important to correct.

Hi Tobias,

Thank you, I appreciate it.

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

This is great news.

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

Do you think it may be relevant to my current problem or is this a
general comment?

> There are many ways this could happen and there's (obviously) a bug
> here,

If that’s a bug, it sounds like one of those that are hard to track
down, at least as long as nobody else is reporting a similar issue.
Maybe another upgrade will help.

Regards,

WŻ

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