[pkg-gnupg-maint] Bug#643341: Bug#643341: libgpg-error-dev: cross-compiling anything based on libgpg-error is painful

[Simon McVittie]

Control: tags -1 - wontfix

On Tue, 16 Oct 2018 at 10:00:03 +0900, NIIBE Yutaka wrote:
> Simon McVittie <smcv at debian.org> wrote:
> > The wontfix tag was because upstream are not willing to add pkg-config
> > metadata
> 
> It was.  Now, it has been changed.

Removing the tag, then. Thanks!

> In the next version of libgpg-error (1.33), we will offer gpg-error.pc
> (if nothing is going wrong).  I believe this change helps
> cross-compiling other packages with libgpg-error.

It does help. Thank you for reconsidering this! The macros in pkg.m4
look for <triplet>-pkg-config before pkg-config, and in Debian,
<triplet>-pkg-config is created by a dpkg hook that sets up the search
path correctly for the <triplet> host architecture, so everything
automatically works as it should.

That will fix cross-compilation if dependent packages are changed to
use (for example) PKG_CHECK_MODULES([GPG_ERROR], [gpg-error >= 1.33])
instead of AM_PATH_GPG_ERROR([1.33]).

If you are willing to change the implementation of AM_PATH_GPG_ERROR
and AM_PATH_GPGRT, then it would be possible to make them use
PKG_CHECK_MODULES, something like this:

    PKG_CHECK_EXISTS(
      [gpg-error >= $min_gpg_error_version],
      [
        dnl Found via pkg-config.
        dnl Populate GPG_ERROR_CFLAGS, GPG_ERROR_LIBS
        PKG_CHECK_MODULES([GPG_ERROR], [gpg-error >= $min_gpg_error_version])
        dnl Populate gpg-error-specific extra variables
        PKG_CHECK_VAR([GPG_ERROR_MT_CFLAGS], [gpg-error], [mtcflags])
        GPG_ERROR_MT_CFLAGS="$GPG_ERROR_CFLAGS${GPG_ERROR_CFLAGS:+ }$GPG_ERROR_MT_CFLAGS"
        PKG_CHECK_VAR([GPG_ERROR_MT_LIBS], [gpg-error], [mtlibs])
        GPG_ERROR_MT_LIBS="$GPG_ERROR_LIBS${GPG_ERROR_LIBS:+ }$GPG_ERROR_MT_LIBS"
      ]
      dnl
      [
        dnl Not found via pkg-config
        ... The old implementation using gpg-error-config ...
      ])

However, none of this solves co-installability in Debian:
libgpg-error-dev:amd64 and libgpg-error-dev:armhf can't be
installed at the same time, because they have different content in
/usr/bin/gpg-error-config, and that will be a problem for as long as
gpg-error-config exists. That's what I was trying to address on this
bug. I don't think this can be fully solved upstream, but patches like
the ones I sent earlier can at least solve it for Debian (because knowing
we're using a Debian package lets us make some assumptions that wouldn't
be valid upstream, like gpg-error being installed into /usr).

> Currently, in our development version (to be 1.33), gpg-error-config
> script itself is not architecture independent (having architecture
> dependent string), because it needs to find the gpg-error.pc file in
> architecture dependent path, just like pkg-config does.

Is https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=src/gpg-error-config-new.in
the new script?

It's very unusual to parse .pc files "by hand" like this. The usual way
to consume .pc files is to run pkg-config (the reference implementation
in C) or pkgconf (a reimplementation in Perl).

For Debian, I wonder whether we might be able to patch the script to
remove this part, which looks like the only architecture variation:

    prefix=@prefix@
    exec_prefix=@exec_prefix@
    libdir=${PKG_CONFIG_LIBDIR:- at libdir@}
    PKG_CONFIG_PATH="$PKG_CONFIG_PATH${PKG_CONFIG_PATH:+:}${libdir}/pkgconfig"

and replace it with something more like this:

    PKG_CONFIG_PATH="$(PKG_CONFIG:-pkg-config) --variable=pc_path pkg-config"

because we know that Debian packages install their .pc files into
pkg-config's default search path anyway? But I'm not sure whether that
will give the right answer when cross-compiling.

> I'm not sure if it's worth to have <triplet>-gpg-error-config command,
> when we have gpg-error.pc.

In any case that would only be useful if AM_PATH_GPG_ERROR was changed
to look for it with AC_PATH_TOOL instead of AC_PATH_PROG; and if you're
going to change the implementation of AM_PATH_GPG_ERROR, it would
probably be better to change it to try using pkg-config in preference
to gpg-error-config.

>From https://codesearch.debian.net/search?q=gpg-error-config&perpkg=1 it
looks as though libaacs and libassuan already have a (patched?) version
of gpg-error.m4 that uses AC_PATH_TOOL, so they are already trying to
find <triplet>-gpg-error-config before falling back to gpg-error-config?

> Nevertheless, I think that it is possible to improve gpg-error-config
> script to detect architecture dependent path dynamically

This is not usually possible. If I run gpg-error-config, for example like
this:

    https://sources.debian.org/src/deja-dup/38.0-1/meson.build/?hl=60#L60

how do you know which architecture I wanted?

    smcv