[pkg-gnupg-maint] Bug#933713: libgpg-error-dev: make package fit for cross development

[Simon McVittie]

(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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-d-tests-build-Extend-to-cover-more-ways-to-find-gpg-.patch
Type: text/x-diff
Size: 1774 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20200429/55bb2830/attachment.patch>