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

[Helmut Grohne]

On Mon, Sep 15, 2014 at 05:17:06PM -0400, Daniel Kahn Gillmor wrote:
> we would need to move /usr/include/gpg-error.h to
> /usr/include/$ARCH/gpg-error.h (since that file varies by architecture).

This move has benefits on its own. See
https://lists.debian.org/debian-devel-announce/2014/08/msg00013.html
section 3.4. Can you implement it even if it does not solve this bug on
its own?

> But the last remaining piece of doing this work is to deal with
> /usr/bin/gpg-error-config, which differs by architecture.
> 
> The first recommendation here:
> 
>   https://wiki.ubuntu.com/MultiarchCross#Executables_in_-dev_packages
> 
> is to help upstream switch to pkg-config, which Werner has explicitly
> stated he has no interest in doing, so that's out.
> 
> All of the recommendations seem pretty problematic, actually, in terms
> of forcing an archive transition -- we'd require our downstream
> dependencies to change how they invoke gpg-error-config.
> 
> One other approach, i suppose, is to modify gpg-error-config itself
> somehow to be able to invoke it with a different triplet (but have it
> default to something sane?)
> 
> I'm really not sure what the best way to approach this is, but i'm open
> to specific suggestions.

Well put. This issue boils down to upstream providing an inexact API.
It cannot be fixed without help from both upstream and library users.
Let me explain why switching to pkg-config would magically solve this
and draft an upstream-acceptable solution from there.

Standard autotools nowadays check whether host architecture differs from
build architecture and if that is the case, prefer build tools that are
prefixed with the gnu triplet of the host architecture. This mechanism
is well tested for pkg-config and works. In particular, the autotools
come with relevant macro files that do this for pkg-config, so library
users hardly get this wrong. In contrast, guile-config (another problem
of this kind) is always executed without that prefix and causes the very
same problem as does gpg-error-config.

What does this mean for libgpg-error?

First and foremost, both libgpg-erorr upstream and Debian should start
providing $PREFIX/bin/$HOST_TRIPLET-gpg-error-config as a symbolic link
to gpg-error-config. Once this is in place, we need to approach
library users to prefer this way of calling gpg-error-config. A good
citizen in this respect is libgcrypt20. Quoting from its cross build
log:

| checking for x86_64-linux-gnux32-gpg-error-config... no
| checking for gpg-error-config... /usr/bin/gpg-error-config

Once all library users are switched, the problem is solved from an
upstream POV.

For Debian there still is a problem, because native builds still need
the script without architecture prefix. We need to deprecate using build
tools without architecture prefix and entirely move away from that.

So while this bug certainly cannot be fixed soonish, it still shows a
number of sub-issues that can be solved today. guile is in the very same
position and will not mark its -dev package M-A:same today, but guile
chose to move to pkg-config and will be able once all guile-config users
have been killed.

Helmut