ok to commit ? @@ -4,6 +4,8 @@ EAPI="3" +inherit toolchain-funcs + DESCRIPTION="General purpose crypto library based on the code used in GnuPG" HOMEPAGE="http://www.gnupg.org/" SRC_URI="mirror://gnupg/libgcrypt/${P}.tar.bz2 @@ -18,6 +20,19 @@ DEPEND="${RDEPEND}" src_configure() { + if tc-is-cross-compiler ; then + # The libgcrypt configure code is really stupid and assumes + # that you have an underscore symbol whenever you cross-compile. + # Ask gcc to see what it does instead. + local symprefix=$($(tc-getCPP) -E - <<<__USER_LABEL_PREFIX__ | tail -1) + case ${symprefix} in + __USER_LABEL_PREFIX__) ;; # nothing we can do here + "") export ac_cv_sys_symbol_underscore=no ;; + _) export ac_cv_sys_symbol_underscore=yes ;; + *) die "unknown symbol prefix: ${symprefix}" ;; + esac + fi + # --disable-padlock-support for bug #201917 econf \ --disable-padlock-support \
nack, this is not upstreamable and we'd have to keep it forever this way — can you get to the source of the trouble, or can you wait for Thursday for me to look at it?
working with upstream gnupg is like pulling teeth. things are working in parallel, not serial, to get resolved. so i'm not going to sit around and see what the gnupg peeps feel like using while the ebuilds stay broken.
Fixed to use libtool's macro to do the same thing. If that leads to wrong results, fix libtool, don't hack libgcrypt.
your change is incomplete. the broken code in acinclude.m4 still remains.
The acinclude.m4 code is dead code since it's not called, and I've sent the removal of it upstream, so the issue is solved as the code is never hit. Please refrain from reopening.
