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

[Simon McVittie]

On Wed, 25 Jul 2018 at 21:59:55 +0100, Simon McVittie wrote:
> 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 [1] would be suitable? It seems to work.

I see there has been an upload of libgpg-error recently. Would you
mind reconsidering whether the wontfix tag on this bug is appropriate?
The wontfix tag was because upstream are not willing to add pkg-config
metadata (which I personally think would have been a better solution,
but they get to choose how their compile-time interfaces work), but the
patches I suggested in [1] don't actually require that.

Thanks,
    smcv

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=643341#88