(For context, I'm following up on this because I'm involved in the Steam
Runtime, a Debian derivative that ships libgcrypt and puts a high value
on being able to combine x86_64 with i386.)

On Fri, 02 Aug 2019 at 13:51:09 +0200, W. Martin Borgert wrote:
> IMHO, this package could be Multi-Arch: same, and therefore
> support cross development easily, if /usr/bin/gpg-error-config
> were renamed to /usr/bin/<multiarch_name>-gpg-error-config, e.g.
> /usr/bin/arm-linux-gnueabi-gpg-error-config.

Finding gpg-error-config in PATH is part of the API, so I don't think
dropping it is going to be an option. If gpgrt.m4 and gpg-error.m4 used
AC_PATH_TOOL (like pkg.m4 does to find i686-linux-gnu-pkg-config in
preference to plain pkg-config), then we could install gpg-error-config
as (for example) i686-linux-gnu-gpg-error-config; but it doesn't, so
we can't.

I think step 1 for all of this is to expand the 'build' autopkgtest
so that it covers all the "APIs" that we need to keep working; and
then we can immediately eliminate any proposed solution that fails the
autopkgtest. I don't know this library well, but please see attached
for a quick attempt at this.

> This probably needs a symlink for the native platform or similar
> to not break existing build processes.

Adding that symlink in the most obvious way would make it not Multi-Arch:
same and we'd be back where we started.

On Tue, 28 Jan 2020 at 13:01:04 +0100, Francois Gouget wrote:
> So I think it is reasonable to stop shipping gpg-error-config, just like
> FreeType stopped shipping freetype-config to become multiarch-compatible.

If it's part of upstream's API, then I don't think that's necessarily
feasible.

On Mon, 17 Feb 2020 at 10:33:04 +0900, NIIBE Yutaka wrote:
> In future release of libgpg-error, gpg-error-config will be a symbolic
> link to gpgrt-config at installation (when detected POSIX compatible
> Borne shell, or we will ignore system with no POSIX compatible Borne
> shell).

Isn't the calling convention different? gpgrt-config requires a --libdir
argument or a PKG_CONFIG_LIBDIR or PKG_CONFIG_PATH; gpg-error-config
doesn't. Debian systems normally don't set PKG_CONFIG_LIBDIR or
PKG_CONFIG_PATH, even for cross-compilation: they run an appropriate
architecture-specific *-linux-gnu*-pkg-config, which sets up the right
search paths internally.

On Sat, 07 Mar 2020 at 16:17:36 +0100, Francois Gouget wrote:
> Now an alternative to removing gpg-error-config is to make it 
> compatible with multiarch.

I think this is likely to be a more viable route.

> -libdir=${prefix}/lib/x86_64-linux-gnu
> +libdir=${prefix}/lib/i386-linux-gnu
> ...
> -           output="$output -L${prefix}/lib/x86_64-linux-gnu -lgpg-error"
> +           output="$output -L${prefix}/lib/i386-linux-gnu -lgpg-error"
> 
> The -L option is not needed on Debian so it might as well be omitted.

Yes, that's a straightforward (Debian-specific) patch.

> -               host) echo "x86_64-pc-linux-gnu" ;;
> +               host) echo "i686-pc-linux-gnu" ;;
> ...
> -            echo "x86_64-pc-linux-gnu"
> +            echo "i686-pc-linux-gnu"
> 
> This one is the real problem. Maybe it can be derived from some other 
> source. Or maybe removing support for host would have less impact than 
> removing gpg-error-config entirely.

gpg-error-config --host (or --variable=host) seems to be used in
gpg-error.m4 to check that we've found the right gpg-error. If it
prints "none", or if the script exits with a nonzero status, then the check
ignores it. So maybe we could patch gpg-error-config to print "none" for
the host, or to exit 1 when asked for it?

Is --host or --variable=host considered to be a "private" interface between
gpg-error-config and gpg-error.m4, or is it part of the "public API"?
If it's "private" then that trick seems fine, but if it's "public" then
I think it's more likely to break things.

The other possibility that I can think of is that we patch gpg-error-config
to determine the host dynamically, by assuming that some suitable
environment variable is set to a suitable value for the cross-compilation
host, and asking it where to look. For example, we could try
multiarch=$(${CC:-cc} -print-multiarch), and if that succeeds/gives
non-empty output, look in /usr/lib/${multiarch}, or try running
gpgrt-config --libdir=/usr/lib/${multiarch} --variable=host, or something
like that.

An alternative route that is essentially equivalent to that one would
be to install upstream's gpg-error-config into the libdir, and have a
Debian-specific wrapper in /usr/bin that uses an appropriate mechanism
(like $(${CC:-cc} -print-multiarch) maybe) to find and exec the right
architecture-specific gpg-error-config.

    smcv
>From c39009617f81c63da3968f8f66927359fa2ed0c5 Mon Sep 17 00:00:00 2001
From: Simon McVittie <s...@debian.org>
Date: Fri, 24 Apr 2020 19:25:17 +0100
Subject: [PATCH] d/tests/build: Extend to cover more ways to find gpg-error

---
 debian/tests/build | 46 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/debian/tests/build b/debian/tests/build
index 195af59..c90105b 100755
--- a/debian/tests/build
+++ b/debian/tests/build
@@ -11,3 +11,49 @@ fi
 ${CROSS_COMPILE}gcc -pedantic -Wall -Werror -o test-run debian/tests/simple-build.c $(${CROSS_COMPILE}pkg-config --cflags --libs gpg-error)
 ./test-run
 rm -f test-run
+
+${CROSS_COMPILE}gcc -pedantic -Wall -Werror -o test-run debian/tests/simple-build.c $(gpg-error-config --cflags --libs)
+./test-run
+rm -f test-run
+
+${CROSS_COMPILE}gcc -pedantic -Wall -Werror -o test-run debian/tests/simple-build.c $(gpg-error-config --mt --cflags --libs)
+./test-run
+rm -f test-run
+
+libdir="/usr/lib/$("${CROSS_COMPILE}gcc" -print-multiarch)"
+
+${CROSS_COMPILE}gcc -pedantic -Wall -Werror -o test-run debian/tests/simple-build.c $(gpgrt-config --libdir="${libdir}" --cflags --libs)
+./test-run
+rm -f test-run
+
+host=$(${CROSS_COMPILE}pkg-config --variable=host gpg-error)
+
+cfg="$(gpg-error-config --variable=host)"
+
+case "$cfg" in
+    ($host)
+        ;;
+
+    (none)
+        ;;
+
+    (*)
+        echo "gpg-error-config thinks host=$cfg, pkg-config thinks host=$host" >&2
+        exit 1
+        ;;
+esac
+
+cfg="$(gpgrt-config --libdir="${libdir}" --variable=host)"
+
+case "$cfg" in
+    ($host)
+        ;;
+
+    (none)
+        ;;
+
+    (*)
+        echo "gpgrt-config thinks host=$cfg, pkg-config thinks host=$host" >&2
+        exit 1
+        ;;
+esac
-- 
2.26.2

Reply via email to