Page MenuHome GnuPG

libgcrypt: gpgrt-config not found in $PREFIX if there are no less-preferred options found via $CC
Closed, ResolvedPublic

Description

We came across a build problem in libgcrypt, concerning finding gpgrt-config from $PREFIX.

We have a slightly unusual build environment, in which $CC is pointing to a compiler we have built (not the system install). In particular, none of the directories on the compiler's libraries search path contain a pkgconfig directory.

We have built our previous dependencies (including libgpg-error 1.46) and installed them in $PREFIX. $PREFIX/lib/pkgconfig exists. Therefore we expect that libgcrpyt's configure script would be able to find gpgrt-config within $PREFIX.

However, the most preferred directories (set as possible_libdir1, possible_libdir2) are searched within a loop of candidates (set as libdir_candidates), generated from the output of $CC -print-search-dirs and filtered on the existence of a pkgconfig directory contained within. If there are no possible results in libdir_candidates, then possible_libdir1 will never be considered even though it is preferred.

I propose a patch in which one entry is always added to libdir_candidates, so that the loop is always executed at least once. (If this entry is not valid, then test -f ${possible_libdir0}/pkgconfig/gpg-error.pc will never be true, gpgrt_libdir is not set and there is no change in behaviour.)

Details

Version
1.10.1

Event Timeline

werner added subscribers: gniibe, werner.

@gniibe: Would you mind to look at this?

werner triaged this task as Normal priority.Mar 21 2023, 3:24 PM

Thank you for the bug report.

I see your problem. We need to improve the patch, as we cannot use Bash-only feature in configure.

To be as small as possible, change is like:

diff --git a/gpg-error.m4 b/gpg-error.m4
index 908e604..0259c10 100644
--- a/gpg-error.m4
+++ b/gpg-error.m4
@@ -115,7 +115,7 @@ AC_DEFUN([_AM_PATH_GPGRT_CONFIG],[dnl
         fi
         if test -n "$gpgrt_libdir"; then break; fi
       done
-      if test -z "$libdir_candidates"; then
+      if test -z "$gpgrt_libdir"; then
         # No valid pkgconfig dir in any of the system directories, fallback
         gpgrt_libdir=${possible_libdir1}
       fi

That is, prefer possible_libdir1 when not used. Please test this.

gniibe changed the task status from Open to Testing.Mar 23 2023, 6:51 AM
gniibe added a project: gpgrt.

Fixed in master (of libgpg-error).
Pushed the change to libgcrypt (master and 1.10 branch).

@gniibe
Trying to crosscompile newer 2.4 gpg toolstack from Heads OSF under PR https://github.com/osresearch/heads/pull/1350

That is
-gpg2_version := 2.4.0
-libassuan_version := 2.5.5
-libgcrypt_version := 1.10.1
-libgpg-error_version := 1.46
-libksba_version := 1.6.3

I attempted to test some of your fixes, without success, which is why i'm here (hello!)

You can see build failing at https://app.circleci.com/pipelines/github/tlaurion/heads/1561/workflows/933c2b4e-c532-4166-bec5-2be8ca9166f2/jobs/19454?invite=true#step-103-1904, for some reason, pkg-config is used but fails against libgpg-error.so not being found, which doesn't make any sense.

Without additional fixes, "/root/project/install/x86/bin/gpg-error-config" is found, but not gpgrt-config in the same directory:
https://app.circleci.com/pipelines/github/tlaurion/heads/1561/workflows/933c2b4e-c532-4166-bec5-2be8ca9166f2/jobs/19454?invite=true#step-103-1193

The main Makefile of Heads project attempts to do the right thing with pkg-config around https://github.com/osresearch/heads/blob/2995376cdaffae4457f3042bfdbd33414b475086/Makefile#L133-L145
Of course, some fixes still need to be applied against configure scripts for crosscompilation, as can be seen as example at:
https://github.com/osresearch/heads/pull/1350/files#diff-46db2ea06eb8b2b2eae641458c1c6e47b36b93828df13d82792fc5dd71a5f35fR8-R9

Any patches you would recommend to be directly applied on top of extracted libgcrypt as defined per module config:
https://github.com/osresearch/heads/pull/1350/files#diff-abfd42c4d776fe2296014ebb23ee8cd3848d1126c1aa808ad194873a34a88f2eR3

@tlaurion Thank you for the report, but your particular problem is irrelevant to this ticket.
I lightly looked the log and noticed that the cross build would have some confusions for pkg-config, however, that's not our problem but yours.
For the particular failures in your build, the issues look like a problem of musl linker. It seems that it requires all dependency of libraries to be used, even if an executable doesn't use a library directly.
If it is the case, we need a patch... something like:

diff --git a/tests/Makefile.am b/tests/Makefile.am
index 75aa5cf7..f8e50dae 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -83,9 +83,6 @@ EXTRA_DIST = README rsa-16k.key \
 
 LDADD = $(standard_ldadd) $(GPG_ERROR_LIBS) @LDADD_FOR_TESTS_KLUDGE@
 pkbench_LDADD = $(standard_ldadd) @LDADD_FOR_TESTS_KLUDGE@
-prime_LDADD = $(standard_ldadd) @LDADD_FOR_TESTS_KLUDGE@
-t_mpi_bit_LDADD = $(standard_ldadd) @LDADD_FOR_TESTS_KLUDGE@
-t_secmem_LDADD = $(standard_ldadd) @LDADD_FOR_TESTS_KLUDGE@
 testapi_LDADD = $(standard_ldadd) @LDADD_FOR_TESTS_KLUDGE@
 t_lock_LDADD = $(standard_ldadd) $(GPG_ERROR_MT_LIBS) @LDADD_FOR_TESTS_KLUDGE@
 t_lock_CFLAGS = $(GPG_ERROR_MT_CFLAGS)

... for musl linker.

If you continue, please open your ticket for musl build.

Thank you for the bug report.

I see your problem. We need to improve the patch, as we cannot use Bash-only feature in configure.
[...]
That is, prefer possible_libdir1 when not used. Please test this.

Thanks for the modified patch. I can confirm that it works in our environment.