Hi Colin, On Tue, Sep 27, 2011 at 01:15:27PM +0100, Colin Watson wrote: > libgpg-error-dev ships its own gpg-error-config program which dependent > packages are supposed to use. Unfortunately this doesn't play > particularly well with standard cross-build setups; nothing knows that > per-architecture versions of gpg-error-config need to be installed in > some kind of per-architecture path, so if you try to cross-build > anything that build-depends on libgpg-error-dev (such as libgcrypt11) it > fails because it tries to link against libgpg-error libraries for the > architecture you're building on rather than the architecture you're > building for.
I have problems reproducing this issue in rebootstrap[1]. Since libgpg-error-dev is M-A:no, a cross builder will just pull in the host version of libgpg-error-dev. This actually works out quite well, because gpg-error-config is a shell script and thus executable for the build architecture. Of course, this means that trying to use it in a native compile will result in garbage. Still crossing reverse build dependencies of libgpg-error-dev such as libgcrypt11 or libgcrypt20 just work in my experience. Their configure scripts first check for <triplet>-gpg-error-config, which is not found, and then fall back to gpg-error-config, which works. So are you talking about cross building in a packaging context (where I do not see a problem) or about cross building for users (where there currently is no packaged toolchain)? Thanks for clarifying Helmut [1] http://wiki.debian.org/HelmutGrohne/rebootstrap -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org