Page MenuHome GnuPG

make check fails for GnuPG with libassuan 3.0.1
Closed, ResolvedPublic

Description

This is from an attempt to build gnupg-2.4.5 on Ubuntu 23.10 under WSL (6.1.21.2-microsoft-standard-WSL2+ kernel)

make  check-TESTS
make[2]: Entering directory '/home/dschulman/Downloads/gnupg-2.4.5/g10'
PASS: t-rmd160
./t-keydb: error while loading shared libraries: libassuan.so.9: cannot open shared object file: No such file or directory
FAIL: t-keydb
./t-keydb-get-keyblock: error while loading shared libraries: libassuan.so.9: cannot open shared object file: No such file or directory
FAIL: t-keydb-get-keyblock
./t-stutter: error while loading shared libraries: libassuan.so.9: cannot open shared object file: No such file or directory
FAIL: t-stutter
./t-keyid: error while loading shared libraries: libassuan.so.9: cannot open shared object file: No such file or directory
FAIL: t-keyid
=======================================
4 of 5 tests failed
Please report to https://bugs.gnupg.org
=======================================
make[2]: *** [Makefile:1006: check-TESTS] Error 1
make[2]: Leaving directory '/home/dschulman/Downloads/gnupg-2.4.5/g10'
make[1]: *** [Makefile:1132: check-am] Error 2
make[1]: Leaving directory '/home/dschulman/Downloads/gnupg-2.4.5/g10'
make: *** [Makefile:631: check-recursive] Error 1

Details

Version
gnupg-2.4.5, libassuan-3.0.1

Event Timeline

Did you used the speedo build method? Did you install libassuan first?

I don't know what the "speedo build method" is, so no. I've built this software many times before with the usual routine:

  1. ./configure
  2. make
  3. make check
  4. sudo make install

And I've always used the following build / install order:

  1. libgpg-error
  2. libksba
  3. libgcrypt
  4. libassuan
  5. npth
  6. pinentry
  7. gnupg

What you should is to to run

$ cd /home/dschulman/Downloads/gnupg-2.4.5/g10
$ ldd ./t-keydb

and check whey it can't find the libs. Did you run the ldconfig before running the tests?

Strange - running sudo ldconfig prior to make check did indeed allow the tests to pass and the gnupg executable to build. I don't recall needing to do that until now; has something changed?

werner claimed this task.
werner added a project: libassuan.

Yes, the SO number changed. Before that you had run the test with an old version of the library or maybe the current one depending on your system. However, a changed SO number means that you have can have two versions of the library installed and they don't alias them with symlinks. We rarely update SO numbers but int he libassuan case we did it because technically we had a minor ABI change but GnuPG and Cie. are not affected; we did it anyway to be correct.