libgcrypt version in core-updates

  • Done
  • quality assurance status badge
Details
2 participants
  • Andreas Enge
  • Ludovic Courtès
Owner
unassigned
Submitted by
Andreas Enge
Severity
normal
A
A
Andreas Enge wrote on 19 Apr 2023 18:28
(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 18: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’.
A
A
Andreas Enge wrote on 19 Apr 2023 20:19
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 62949@debbugs.gnu.org)
ZEAwlrweoke8c1Hp@jurong
Am Wed, Apr 19, 2023 at 06:37:08PM +0200 schrieb Ludovic Courtès:
Toggle quote (4 lines)
> 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
L
L
Ludovic Courtès wrote on 19 Apr 2023 22:40
(name . Andreas Enge)(address . andreas@enge.fr)(address . 62949@debbugs.gnu.org)
871qkfhagj.fsf@gnu.org
Hi,

Andreas Enge <andreas@enge.fr> skribis:

Toggle quote (22 lines)
> 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.
L
L
Ludovic Courtès wrote on 19 Apr 2023 22:40
control message for bug #62949
(address . control@debbugs.gnu.org)
87zg73fvvq.fsf@gnu.org
tags 62949 notabug
close 62949
quit
?
Your comment

This issue is archived.

To comment on this conversation send an email to 62949@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 62949
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