[core-updates] pre-inst-env no longer works

  • Done
  • quality assurance status badge
Details
5 participants
  • Andreas Enge
  • Brian Cully
  • Josselin Poiret
  • Ludovic Courtès
  • Simon Tournier
Owner
unassigned
Submitted by
Brian Cully
Severity
normal

Debbugs page

B
B
Brian Cully wrote on 18 Apr 2023 07:51
(address . bug-guix@gnu.org)
878repnsqp.fsf@psyduck.jhoto.kublai.com
After re-configuring my system with core updates and rebooting,
I'm no longer able to use Guix' ‘pre-inst-env’ command to do
testing:

Toggle snippet (13 lines)
~/src/guix-core-updates $ ./pre-inst-env -- guix build zsh
hint: Consider installing the `glibc-locales' package and defining
`GUIX_LOCPATH', along these lines:

guix install glibc-locales
export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

guix build: error: gcry_md_hash_buffer: Function not implemented
~/src/guix-core-updates $

System guix (which is now from core-updates on my system) works
fine:

Toggle snippet (4 lines)
~/src/guix-core-updates $ guix build zsh
/gnu/store/viwf9ar2cgly6im3yk9wf2c1dq8l1z3g-zsh-5.8.1

I'm not sure what's going on with the locales warning above, but I
assume it's related to #62934.

-bjc
S
S
Simon Tournier wrote on 19 Apr 2023 01:51
86a5z4jluo.fsf@gmail.com
Hi,

On Tue, 18 Apr 2023 at 10:51, Brian Cully via Bug reports for GNU Guix <bug-guix@gnu.org> wrote:

Toggle quote (2 lines)
> ~/src/guix-core-updates $ ./pre-inst-env -- guix build zsh

Are you sure about the dash-dash (--) with ./pre-inst-env?

I get this:

Toggle snippet (11 lines)
$ ./pre-inst-env guix describe
Git checkout:
repository: /home/simon/src/guix/wk/core-updates/
branch: core-updates
commit: 1c86be2fd69d84f536518cc5e4a32c067e851709

$ ./pre-inst-env -- guix describe
./pre-inst-env: 55: exec: --: not found


Cheers,
simon
B
B
Brian Cully wrote on 19 Apr 2023 04:29
(name . Simon Tournier)(address . zimon.toutoune@gmail.com)(address . 62936@debbugs.gnu.org)
87wn28umx8.fsf@psyduck.jhoto.kublai.com
Simon Tournier <zimon.toutoune@gmail.com> writes:

Toggle quote (15 lines)
>> ~/src/guix-core-updates $ ./pre-inst-env -- guix build zsh
>
> Are you sure about the dash-dash (--) with ./pre-inst-env?
>
> I get this:
>
> $ ./pre-inst-env guix describe
> Git checkout:
> repository: /home/simon/src/guix/wk/core-updates/
> branch: core-updates
> commit: 1c86be2fd69d84f536518cc5e4a32c067e851709
>
> $ ./pre-inst-env -- guix describe
> ./pre-inst-env: 55: exec: --: not found

Odd. I didn't think it made a difference (though I don't currently
have a working ‘pre-inst-env’) to check with. Do note that the
error you're seeing is different from the one I posted, and
explicable.

If I try without the double dash, there's no difference for me:

Toggle snippet (12 lines)
~/src/guix-core-updates $ ./pre-inst-env guix build emacs-magit
hint: Consider installing the `glibc-locales' package and defining
`GUIX_LOCPATH', along these lines:

guix install glibc-locales
export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

guix build: error: gcry_md_hash_buffer: Function not implemented

As a fun aside, using ‘guix describe’ also fails, though at a
different C binding point:

Toggle snippet (54 lines)
~/src/guix-core-updates $ ./pre-inst-env guix describe
hint: Consider installing the `glibc-locales' package and defining
`GUIX_LOCPATH', along these lines:

guix install glibc-locales
export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"

See the "Application Setup" section in the manual, for more info.

Backtrace:
In ice-9/threads.scm:
390:8 19 (_ _)
In ice-9/boot-9.scm:
3253:13 18 (_)
In ice-9/threads.scm:
390:8 17 (_ _)
In ice-9/boot-9.scm:
3544:20 16 (_)
2836:4 15 (save-module-excursion _)
3564:26 14 (_)
In unknown file:
13 (primitive-load-path "guix/channels" #<procedure
7f7677c326e0 at ice-9/boot-9.scm:3551?>)
In ice-9/boot-9.scm:
3923:23 12 (_)
3411:4 11 (define-module* _ #:filename _ #:pure _ #:version _
#:imports _ #:exports _ # _ # _ # _ ?)
3424:24 10 (_)
222:17 9 (map1 (((git)) ((guix git)) ((guix git-authenticate))
((guix openpgp) #:select (?)) # ?))
3327:17 8 (resolve-interface (git) #:select _ #:hide _ #:prefix
_ #:renamer _ #:version _)
In ice-9/threads.scm:
390:8 7 (_ _)
In ice-9/boot-9.scm:
3253:13 6 (_)
In ice-9/threads.scm:
390:8 5 (_ _)
In ice-9/boot-9.scm:
3544:20 4 (_)
2836:4 3 (save-module-excursion #<procedure 7f7677c206f0 at
ice-9/boot-9.scm:3545:21 ()>)
3564:26 2 (_)
In unknown file:
1 (primitive-load-path "git" #<procedure 7f7677c32460
at ice-9/boot-9.scm:3551:37 ()>)
In git/bindings.scm:
66:8 0 (_ . _)

git/bindings.scm:66:8: In procedure git_libgit2_init: Function not
implemented


-bjc
L
L
Ludovic Courtès wrote on 19 Apr 2023 06:41
(name . Brian Cully)(address . bjc@spork.org)
87leiogfa3.fsf@gnu.org
Hi,

Brian Cully <bjc@spork.org> skribis:

Toggle quote (3 lines)
> git/bindings.scm:66:8: In procedure git_libgit2_init: Function not
> implemented

That indicates that Guile-Git failed to load libgit2.so, which could be
because libgit2.so is linked against a different libc version (since
you’re testing core-updates).

Make sure everything is in sync, and use ‘guix shell -D guix -C’ to
avoid interference!

Thanks,
Ludo’.
L
L
Ludovic Courtès wrote on 19 Apr 2023 06:42
control message for bug #62936
(address . control@debbugs.gnu.org)
87jzy8gf9m.fsf@gnu.org
tags 62936 notabug
close 62936
quit
B
B
Brian Cully wrote on 19 Apr 2023 07:14
Re: bug#62936: [core-updates] pre-inst-env no longer works
(name . Ludovic Courtès)(address . ludo@gnu.org)
87r0sg0x8r.fsf@psyduck.jhoto.kublai.com
Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (4 lines)
> Make sure everything is in sync, and use ‘guix shell -D guix -C’
> to
> avoid interference!

This has made the glibc locale error and the libgit2 bindings to
work. Thank you!

However, I'm not sure how this happened in the first place. The
system I'm running on is running core-updates, from a ‘guix system
reconfigure’ and reboot. Where is the improperly linked libgit2
coming from that guix is loading it (and then, only when used with
‘pre-inst-env’).

-bjc
A
A
Andreas Enge wrote on 19 Apr 2023 09:28
libgcrypt version in core-updates
(address . bug-guix@gnu.org)(address . 62936@debbugs.gnu.org)
ZEAWryOf8oblZG1l@jurong
Hello,

this looks to me like it could be a duplicate of #62936, but since this
bug is closed, I am simply opening a new one.

The libgcrypt version was updated from 1.8.8 to 1.10.1 from master to
core-updates.

This causes ./configure to fail like so:
...
checking for gcry_md_open in -lgcrypt... no
checking for gcrypt.h... yes
configure: error: GNU libgcrypt not found; please install it

I suppose that the same problem occurred in #62936, but did not manifest
itself as clearly since one usually does not rerun configure.

It looks as if the API changed incompatibly between the two versions.

Andreas
L
L
Ludovic Courtès wrote on 19 Apr 2023 09:37
(name . Andreas Enge)(address . andreas@enge.fr)
877cu7hlqj.fsf@gnu.org
Hallo!

Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (15 lines)
> this looks to me like it could be a duplicate of #62936, but since this
> bug is closed, I am simply opening a new one.
>
> The libgcrypt version was updated from 1.8.8 to 1.10.1 from master to
> core-updates.
>
> This causes ./configure to fail like so:
> ...
> checking for gcry_md_open in -lgcrypt... no
> checking for gcrypt.h... yes
> configure: error: GNU libgcrypt not found; please install it
>
> I suppose that the same problem occurred in #62936, but did not manifest
> itself as clearly since one usually does not rerun configure.

Given that the ‘guix’ package builds fine on ‘core-updates’, it’s most
likely a build environment issue.

What does ‘config.log’ say?

Ludo’.
B
B
Brian Cully wrote on 19 Apr 2023 12:51
Re: bug#62936: [core-updates] pre-inst-env no longer works
(name . Andreas Enge)(address . andreas@enge.fr)(address . 62936@debbugs.gnu.org)
877cu77irv.fsf_-_@psyduck.jhoto.kublai.com
I did a full rebuild before submitting this bug: bootstrap -> configure
-> make clean -> make.

FWIW, I still have the issue with ‘pre-inst-env’ when not run from
within ‘guix shell -D guix’, which is a step I have never previously
needed. As I just explained on IRC:

Toggle snippet (10 lines)
<bjc> i'm confused why it's suddenly a problem, though. i've never needed to
use ‘guix shell’ with pre-inst-env before [15:41]
<bjc> ludo says it's libgit2 linking against an old libc, but i have no idea
how that's even possible
<bjc> for one thing: my system has been reconfigured. all my packages are now
running core-updates, and that includes libgit2. for another: doesn't
libgit link with a specific path in /gnu/store, so it'll use whatever
glibc it needs regardless of what's in my “system” configuration?

Even if this is some particular problem to my build environment somehow,
I'd love an explanation as to what's going on because I'm extremely
confused.

In case it matters, I've re-run ‘system reconfigure’ and ‘home
reconfigure’ since moving to core-updates, thinking maybe there's some
bootstrapping issue. I'm now 2 system and home generations into
core-updates, but I have the same problem.

Thanks,
J
J
Josselin Poiret wrote on 24 Apr 2023 01:34
(address . 62936@debbugs.gnu.org)
87r0s9vfuc.fsf@jpoiret.xyz
Hello everyone,

Brian Cully via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Toggle quote (29 lines)
> I did a full rebuild before submitting this bug: bootstrap -> configure
> -> make clean -> make.
>
> FWIW, I still have the issue with ‘pre-inst-env’ when not run from
> within ‘guix shell -D guix’, which is a step I have never previously
> needed. As I just explained on IRC:
>
> --8<---------------cut here---------------start------------->8---
> <bjc> i'm confused why it's suddenly a problem, though. i've never needed to
> use ‘guix shell’ with pre-inst-env before [15:41]
> <bjc> ludo says it's libgit2 linking against an old libc, but i have no idea
> how that's even possible
> <bjc> for one thing: my system has been reconfigured. all my packages are now
> running core-updates, and that includes libgit2. for another: doesn't
> libgit link with a specific path in /gnu/store, so it'll use whatever
> glibc it needs regardless of what's in my “system” configuration?
> --8<---------------cut here---------------end--------------->8---
>
> Even if this is some particular problem to my build environment somehow,
> I'd love an explanation as to what's going on because I'm extremely
> confused.
>
> In case it matters, I've re-run ‘system reconfigure’ and ‘home
> reconfigure’ since moving to core-updates, thinking maybe there's some
> bootstrapping issue. I'm now 2 system and home generations into
> core-updates, but I have the same problem.
>
> Thanks,

Ran into this problem myself, here's the reason and the fix:

We build a modified `guile` executable in the source tree (for reasons),
and use that to run guix. Note that it is only added to PATH by
./pre-inst-env! That guile executable is linked against glibc, and so
after upgrading to a newer glibc, it isn't rebuilt (I don't know how
autotools cope with external dependencies getting updated). So glibc
2.33 gets loaded, and once (gcrypt) tries to open the libgcrypt library,
it fails because that newer library needs at least glibc 2.34. The
solution is just to `rm guile` inside of the checkout and run `make`
again.

Best,
--
Josselin Poiret
-----BEGIN PGP SIGNATURE-----

iQHEBAEBCAAuFiEEOSSM2EHGPMM23K8vUF5AuRYXGooFAmRGPwsQHGRldkBqcG9p
cmV0Lnh5egAKCRBQXkC5FhcaijV+DACknJ64abWVamdezYMo9tf4F+I2j40NljWu
ASKW06eXxO+Ucx/5YqdoiZTBx+cQAEqvY927/i+t5A4rW/erbJC2rGSCbSNIZUqC
Mmx2Ac00yqX97TD8O/KGwBRGHvoiKzVnsme8k9vUJgMRGWsKsiWbHj+qTVcM0cUI
dAq7M+kwVLbUQgHv83llaVqnyFztWiXQZ/tN7tYo/EPO6wWXrs2e8jPcsZdWg7+0
BBnWMhoyovt94yh98JSI7KjEwq1DR/kihxaqfmuRlqSFcdi9LOgi/3kjjayxgN1G
I9e65OXP+tW03bpKP+LSfjulS8OSdkDXxJ4KBXsAAb8K5GNdhu0kfmRqC8118edk
78sR8QH0tW04rvlNFIlMLBI537CK2BBB6Ou+lGmW43IFk2XKeuX8znPgCITCLzDS
wGRp1xvp+5BvdsLz1JSjhQzOgAJckWN9JLNEAf1sqNKK1jV7vQe6fRjyl3dqveGs
gPG84tXfiptuKrObsY1l82jIM5+eTnY=
=2T9d
-----END PGP SIGNATURE-----

B
B
Brian Cully wrote on 24 Apr 2023 07:44
(name . Josselin Poiret)(address . dev@jpoiret.xyz)
87edo949o7.fsf@psyduck.jhoto.kublai.com
Josselin Poiret <dev@jpoiret.xyz> writes:

Toggle quote (19 lines)
> Ran into this problem myself, here's the reason and the fix:
>
> We build a modified `guile` executable in the source tree (for
> reasons),
> and use that to run guix. Note that it is only added to PATH by
> ./pre-inst-env! That guile executable is linked against glibc,
> and so
> after upgrading to a newer glibc, it isn't rebuilt (I don't know
> how
> autotools cope with external dependencies getting updated). So
> glibc
> 2.33 gets loaded, and once (gcrypt) tries to open the libgcrypt
> library,
> it fails because that newer library needs at least glibc 2.34.
> The
> solution is just to `rm guile` inside of the checkout and run
> `make`
> again.

With a lot of help on IRC, the culprit was discovered: you *must*
run ‘guix pull --branch=core-updates’ to update your current
profile's guix. This is because guix does not update itself
without the pull.

Without this step, the guix in your user profile will keep around
its old rules about which C compiler to use, which, in turn, pulls
in the old glibc, which causes the error I initially reported.

-bjc
?
Your comment

This issue is archived.

To comment on this conversation send an email to 62936@patchwise.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 62936
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch