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

[Daniel Kahn Gillmor]

On 09/16/2014 02:49 AM, Helmut Grohne wrote:
> 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?

I've made this change with libgpg-error 1.16-1, which i just uploaded to
unstable.

> 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.

Hm, this is interesting.  What if we actually shipped gpg-error-config
as /usr/bin/$HOST_TRIPLET-gpg-error-config and made
/usr/bin/gpg-error-config the symlink via the /etc/alternatives mechanism?

This might let us mark gpg-error-config M-A:same, while still building
cleanly by default for native builds and cross-builds for well-behaved
dependencies.

That means that only cross-building for poorly-behaved dependencies
would be adversely affected, which seems like a much more narrow scope.

> 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.

sure, but that's only critically relevant for cross-building of debian
core, right?

> 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.

Alas, i'm pretty sure that gpg-error upstream won't move to pkg-config
(see the thread starting at [0] for example).

What do you think of the approach i describe above (shipping
gpg-error-config with a tuple prefix, and using /etc/alternatives for
gpg-error-config)?

	--dkg

[0] http://lists.gnupg.org/pipermail/gnupg-devel/2014-May/028473.html


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20140918/18a23941/attachment-0001.sig>