bug#62936: [core-updates] pre-inst-env no longer works

bug#62936: [core-updates] pre-inst-env no longer works

[Brian Cully via Bug reports for GNU Guix]

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:

--8<---------------cut here---------------start------------->8---
~/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 $ 
--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---
~/src/guix-core-updates $ guix build zsh
/gnu/store/viwf9ar2cgly6im3yk9wf2c1dq8l1z3g-zsh-5.8.1
--8<---------------cut here---------------end--------------->8---

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

-bjc

bug#62936: [core-updates] pre-inst-env no longer works

[Simon Tournier]

Hi,

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

> ~/src/guix-core-updates $ ./pre-inst-env -- guix build zsh

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

I get this:

--8<---------------cut here---------------start------------->8---
$ ./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
--8<---------------cut here---------------end--------------->8---


Cheers,
simon

bug#62936: [core-updates] pre-inst-env no longer works

[Brian Cully via Bug reports for GNU Guix]

Simon Tournier <zimon.toutoune@gmail.com> writes:

>> ~/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:

--8<---------------cut here---------------start------------->8---
~/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
--8<---------------cut here---------------end--------------->8---

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

--8<---------------cut here---------------start------------->8---
~/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
--8<---------------cut here---------------end--------------->8---


-bjc

bug#62936: [core-updates] pre-inst-env no longer works

[Ludovic Courtès]

Hi,

Brian Cully <bjc@spork.org> skribis:

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

bug#62936: [core-updates] pre-inst-env no longer works

[Brian Cully via Bug reports for GNU Guix]

Ludovic Courtès <ludo@gnu.org> writes:

> 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

bug#62949: libgcrypt version in core-updates

[Andreas Enge]

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

bug#62949: libgcrypt version in core-updates

[Ludovic Courtès]

Hallo!

Andreas Enge <andreas@enge.fr> skribis:

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

bug#62949: libgcrypt version in core-updates

[Andreas Enge]

Am Wed, Apr 19, 2023 at 06:37:08PM +0200 schrieb Ludovic Courtès:
> Given that the ‘guix’ package builds fine on ‘core-updates’, it’s most
> likely a build environment issue.
> What does ‘config.log’ say?

My environment is Debian on aarch64, with Guix as the package manager.
So it is possible that the Debian environment disturbs what is happening;
but I see the problem depending on whether I install the new or the old
libgcrypt from Guix.

Here are lines from config.log with things related to crypto in them:
configure:8987: checking whether Guile-Gcrypt is available and recent enough
configure:9005: result: yes
...
configure:9062: WARNING: The Guile-Lib requirement was not satisfied (>= 0.2.7);
Some features such as the Go importer will not be usable.
    (not crypto related, but suspicious)
...
configure:9435: checking for libgcrypt-config
configure:9458: found /home/andreas/.guix-profile/bin/libgcrypt-config
configure:9470: result: /home/andreas/.guix-profile/bin/libgcrypt-config
configure:9478: checking libgcrypt's library directory
configure:9490: result: /gnu/store/2xsdih7m18d0f2kiicxrh9pwinjfwzkj-libgcrypt-1.10.1/lib
configure:10900: checking for gcry_md_open in -lgcrypt
configure:10922: g++ -o conftest -g -O2    conftest.cpp -lgcrypt   >&5
ld: /home/andreas/.guix-profile/lib/libgpg-error.so.0: undefined reference to `pthread_mutex_trylock@GLIBC_2.34' 
collect2: error: ld returned 1 exit status
configure:10922: $? = 1
configure: failed program was:
...
configure:10932: result: no
configure:10941: checking for gcrypt.h
configure:10941: g++ -c -g -O2  conftest.cpp >&5
configure:10941: $? = 0
configure:10941: result: yes
configure:10950: error: GNU libgcrypt not found; please install it.

So this is not related to libgcrypt, but to libgpg-error.so linked with an old
glibc; we should be at 2.35 in core-updates, no?

Strangely enough, when I do ldd on /home/andreas/.guix-profile/lib/libgpg-error.so.0
then it is linked with /gnu/store/...-glibc-2.35/lib/libc.so.

Where does this pthread_mutex_trylock@GLIBC_2.34 come from?

I tried "guix shell --pure -D guix" and then "./configure", but the result
is the same.

I will try again on my pure Guix machine.

Andreas

bug#62949: libgcrypt version in core-updates

[Ludovic Courtès]

Hi,

Andreas Enge <andreas@enge.fr> skribis:

> My environment is Debian on aarch64, with Guix as the package manager.
> So it is possible that the Debian environment disturbs what is happening;
> but I see the problem depending on whether I install the new or the old
> libgcrypt from Guix.
>
> Here are lines from config.log with things related to crypto in them:
> configure:8987: checking whether Guile-Gcrypt is available and recent enough
> configure:9005: result: yes
> ...
> configure:9062: WARNING: The Guile-Lib requirement was not satisfied (>= 0.2.7);
> Some features such as the Go importer will not be usable.
>     (not crypto related, but suspicious)
> ...
> configure:9435: checking for libgcrypt-config
> configure:9458: found /home/andreas/.guix-profile/bin/libgcrypt-config
> configure:9470: result: /home/andreas/.guix-profile/bin/libgcrypt-config
> configure:9478: checking libgcrypt's library directory
> configure:9490: result: /gnu/store/2xsdih7m18d0f2kiicxrh9pwinjfwzkj-libgcrypt-1.10.1/lib
> configure:10900: checking for gcry_md_open in -lgcrypt
> configure:10922: g++ -o conftest -g -O2    conftest.cpp -lgcrypt   >&5
> ld: /home/andreas/.guix-profile/lib/libgpg-error.so.0: undefined reference to `pthread_mutex_trylock@GLIBC_2.34' 

That’s the thing: you have libgpg-error.so linked against glibc 2.33
popping up, and that doesn’t fly with glibc 2.35¹.

You need to pick up one consistent environment (with a single glibc
version) and stick to it.  The most reliable way to do that is by using
‘guix shell -C -D guix’ and then running “make clean” to begin with.

HTH!

Ludo’.

¹ The details are in the ‘NEWS’ for glibc 2.34:

  * In order to support smoother in-place-upgrades and to simplify
    the implementation of the runtime all functionality formerly
    implemented in the libraries libpthread, libdl, libutil, libanl has
    been integrated into libc.  New applications do not need to link with
    -lpthread, -ldl, -lutil, -lanl anymore.

bug#62936: [core-updates] pre-inst-env no longer works

[Brian Cully via Bug reports for GNU Guix]

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,

bug#62936: [core-updates] pre-inst-env no longer works

[Josselin Poiret via Bug reports for GNU Guix]

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

Hello everyone,

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

> 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

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

bug#62936: [core-updates] pre-inst-env no longer works

[Brian Cully via Bug reports for GNU Guix]

Josselin Poiret <dev@jpoiret.xyz> writes:

> 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