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