Resolved according to freebsd tracker.

Well, on FreeBSD 10 "uname -p" works the same as "uname -m". It is not POSIX
though.

WTF happened to config.guess? Upstream's ChangeLog has these entries:

2011-08-20 Ben Elliston <bje@gnu.org>

• config.guess (*:FreeBSD:*:*): Switch on ${UNAME_PROCESSOR}.
• testsuite/config-guess.data: Remove hard to test FreeBSD cases.

2006-04-26 Bruno Haible <bruno@clisp.org>

	    Ben Elliston  <bje@gnu.org>

• config.guess (amd64:FreeBSD:*:*) Detect as x86_64.
• testsuite/config-guess.data: Add test case.

Thus in 2006 support form and64 was added and in 2011 the faulty
"uname -p" was implemented and test cases removed. I assume that
everyone patched similar to what you suggested. However, the correct
thing is to fix config.guess.

Unfortunately I do not have access to any FreeBSD box right now (the
FreeBSD in the gcc compile farm is offline). Can you do some tests on
several FreeBSD boxes or give me access to a test box?

What are the patches to configure I see in the build log? And why are
the M4 files are patched - they are not used after configure has been
created? I would also like to see the config.rpath to see how it has been
changed.

Feel free to continue by private mail.

No, FreeBSD has amd64 as uname -m value.

That should not be required. Did you explicitly specify host with
configure?

config.guess has this code:

*:FreeBSD:*:*)

UNAME_PROCESSOR=/usr/bin/uname -p
case ${UNAME_PROCESSOR} in

	    amd64)
		echo x86_64-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;

to map "amd64" to "x86_64" and config.sub called with "amd64" also
returns the canonical "x86_64". Thus everything should be fine.

(I think "amd64" would have been the better and easier to type name,
but the GCC developers settled for "x86_64").

D201: 439_patch-configure.diff

By patching configure it's possible to connect the cipher/*-amd64.S to the build.

See attached.

You better take that to ArchLinux. We can't debug the system for you. Of
course I will help fixing the problem if you post your findings to gnupg-devel.

Issue also occurs in 1.6.1.

D191: 426_darwin_ppc.diff

Thanks, it's no problem to wait until 1.6.2. I just tested the patch and it's
working as intended.

Oh no!

I recall that I looked up the commit id this morning but obviously was disturbed
and thus didn't actually complete the cherry-pick. Sorry. I just pushed the
change. We need to wait some time before we can do a 1.6.2.

I attach a patch for 1.6.1.

D187: 422_0001-cipher-Take-care-of-ENABLE_NEON_SUPPORT.patch

Did you intend to include the changes in 1.6.1? It doesn't appear that they made
it into the release.

Done and 1.6.1 released

Thanks. I backport it tomorrow.

I just tested with the changes applied to the LIBGCRYPT-1-6-BRANCH head, minus
the sha1.c changes (since the NEON parts weren't there), and it is building and
running fine for me. I assume it should work fine in master given this, and can
test that later if you would like, I'm just currently missing the libgpg-error >=
1.13 dependency for doing that. Thanks for your help getting this fixed up.

Fixed in master with commit 52f7c48.
Can you test it with master or should I do a backport to 1.6 first?

Fixed with commit fb8d8517 for 1.6.1

Backported for 1.6.1

Fixed for master with commit cbdc355.

Thanks.

Changing category to dismngr to remind about doing a release.

Looks good, compiling with libgcrypt-1.6.0 and creating a signed S/MIME e-mail
with gpgsm works.

Oh well, backporting is easy enough. Commit id f6bd8ed, will go into 1.6.1.

Will you be so kind and test the attached patch?

D186: 419_dirmngr-pth-fix.patch

This has meanwhile been fixed in master with commit 9edcf109.
I don't see a reason tobackport it to 1.6.

I don't think it makes sense to backport it to 1.5 - it has been this way for so
long. Users of 1.5 should upgrade to 1.6.0.

And in master with commit 5f2af6c2

Fixed for 1.6.1 with commit 36214bfa.

Thanks.

Fixed in master. Thanks.

References:

OpenSSL
http://git.openssl.org/gitweb/?
p=openssl.git;a=blob;f=crypto/ecdsa/ecs_ossl.c;h=adab1f74b41daf6e719ca1fdae1ba81
7085c7802;hb=HEAD#l309

Nettle:
http://git.lysator.liu.se/nettle/nettle/blobs/master/ecc-ecdsa-sign.c#line86
http://git.lysator.liu.se/nettle/nettle/blobs/master/ecc-hash.c

NSS:
https://hg.mozilla.org/projects/nss/file/49360b638350/lib/freebl/ec.c#l746

Done something similar for master; needs to be backported to 1.5.

Support is already in master and in the soon to be released 1.6.0

Libgcrypt 1.6 will be released this year.

Duplicate of T1547

See T1547

D178: 385_libgcrypt-rndlinux.patch

Fixed in master.

Fixed. see T1384.

Fixed for 1.5 and master. Only yet tested for 1.5 on an ultra64 (gcc63).