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

[Simon McVittie]

Control: tags -1 + patch

On Tue, 04 Feb 2014 at 01:34:19 +0900, Osamu Aoki wrote:
> I recently packaged a package with custom *-config and hit by multiarch
> bug for -dev package like this one
[...]
> Since this was caused by hardcoding @libdir@ path into shell code, 
> I replaced that @libdir@ part of code with 
> 
>   /usr/lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)

While looking at this bug as a result of a package I maintain (ostree)
gaining a direct dependency on libgpg-error, it occurred to me that for
the special case of Debian, there's no reason why the -config script
needs to know about @libdir@ at all: passing -L/usr/lib/x86_64-linux-gnu
to the linker is unnecessary, because that's in our version of gcc's
search path anyway.

This is probably the only reason why it's possible to cross-compile
packages that depend on libgpg-error, in fact.

gpg-error-config does include another architecture-dependent string,
which is its response to the --host command-line argument. However,
that command-line argument is undocumented, and only seems to be used
by gpg-error.m4 (and its clone gpgrt.m4), which copes gracefully if
it's rejected: a gpg-error-config for which --host fails is treated
as potentially being from any architecture.

So perhaps the attached would be suitable? It seems to work.

    smcv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-a-simple-compile-link-execute-autopkgtest-for-li.patch
Type: text/x-diff
Size: 1555 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20180725/fd0f7304/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Modify-usr-bin-foo-config-to-be-architecture-indepen.patch
Type: text/x-diff
Size: 4118 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20180725/fd0f7304/attachment-0001.patch>