installation configure script says "Cannot find libgcrypt" although libgcrypt is installed

[Profilsicherheit - Administrator]

Dear list,

I am new to shishi, and ran across this problem when installing it:

First I installed libgpg-error version 1.18
Then I installed libgcrypt version 1.6.2

configure: error: Cannot find libgcrypt
/lib/x86_64-linux-gnu/libgcrypt.so.11
/lib/x86_64-linux-gnu/libgcrypt.so.11.8.2
/usr/local/bin/libgcrypt-config
/usr/local/lib/libgcrypt.la
/usr/local/lib/libgcrypt.so
/usr/local/lib/libgcrypt.so.20
/usr/local/lib/libgcrypt.so.20.0.2
/usr/local/share/aclocal/libgcrypt.m4
configure -with-libgcrypt-prefix=/usr/local/

Unfortunately, I get the same result.
I checked the configure.log and narrowed it down the configure-script
checking for the variable ac_cv_libgrypt, which is set to "yes" in case
the function ac_fn_c_try_link is confirming that the link works. In my
case, the confirmation is probably not given.

Has anyone had the same problem, or any suggestions what I should try to
do next? Any help is much appreciated,

Best regards,
Paul

[Test User]

configure: error: Cannot find libgcrypt
/lib/x86_64-linux-gnu/libgcrypt.so.11
/lib/x86_64-linux-gnu/libgcrypt.so.11.8.2

...

configure -with-libgcrypt-prefix=/usr/local/

I was just trying to compile shishi today and had the same problem
(which I solved) and another one that I am here to report.

The problem is the test for libgcrypt in the configure script. Look for
the section:
#include <gcrypt.h>
/* GCRY_MODULE_ID_USER was added in 1.4.4 and gc-libgcrypt.c
will fail on startup if we don't have 1.4.4 or later, so
test for it early. */
#if !defined GCRY_MODULE_ID_USER
error too old libgcrypt
#endif

The constant GCRY_MODULE_ID_USER was *removed* in version 1.6, so
the test fais in newer versions. You have to modify the test so
that it will pass. I changed my test to:
#if !defined GCRY_MODULE_ID_USER && (GCRYPT_VERSION_NUMBER < 0x010404)

I don't know why they did not use GCRYPT_VERSION_NUMBER in the first
place. Perhaps that constant did not exist at that time.

For what it is worth , you can see
http://upstream.rosalinux.ru/compat_reports/libgcrypt/1.5.4_to_1.6.0/abi_compat_report.html,
which describes the removal of the constant.

[Mats Erik Andersson]

Post by Test User
The constant GCRY_MODULE_ID_USER was *removed* in version 1.6, so
the test fais in newer versions. You have to modify the test so
#if !defined GCRY_MODULE_ID_USER && (GCRYPT_VERSION_NUMBER < 0x010404)
I don't know why they did not use GCRYPT_VERSION_NUMBER in the first
place. Perhaps that constant did not exist at that time.

It was added in version 1.6.0, so it is useless for detection uses!

In fact, the file 'm4/gc.m4' is copied from 'gl/m4/gc.m4', maintained
by Gnulib. I have just helped in updating that file for upstream, and
have also pushed the same change into our development tree. Thus Git
HEAD is now buildable with libgcrypt-1.6.3, as is present in Debian.

Building shishi-1.0.2 just needs the same update of 'gl/m4/gc.m4'
and a corresponding autoreconf consolidation.

Best regards,
M E A

[Test User]

[snip]

Post by Mats Erik Andersson

Post by Test User
I don't know why they did not use GCRYPT_VERSION_NUMBER in the first
place. Perhaps that constant did not exist at that time.

It was added in version 1.6.0, so it is useless for detection uses!

Actually, since the value of an un#defined macro is 0, my proposed test
will work whether GCRYPT_VERSION_NUMBER is defined or not. Even if it
did not work, it would be easy to make it work:

#if defined(GCRYPT_VERSION_NUMBER)
...
#elif defined(GCRY_MODULE_ID_USER)
...
#endif
...

As you say, it has been fixed, but there is a problem.

Regards
Test User

[Mats Erik Andersson]

Post by Test User

Post by Mats Erik Andersson
It was added in version 1.6.0, so it is useless for detection uses!

Actually, since the value of an un#defined macro is 0, my proposed test
will work whether GCRYPT_VERSION_NUMBER is defined or not. Even if it
#if defined(GCRYPT_VERSION_NUMBER)
...
#elif defined(GCRY_MODULE_ID_USER)
...
#endif
...
As you say, it has been fixed, but there is a problem.

The file is not out of our own hand, since we import it
from Gnulib. Therefore we have to get any change accepted
there, which I did achieve with a use of the preferred
macro mechanism published by the upstream Gcrypt project.

For a local build any working patch is usable, but our
design choice is to base a fair amount of code on Gnulib.

Thanks for reporting this issue,
M E Andersson