Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 766423

Summary: dev-libs/libgcrypt-1.9.0: allow disabling NEON
Product: Gentoo Linux Reporter: David Michael <fedora.dm0>
Component: Current packagesAssignee: Mikle Kolyada (RETIRED) <zlogene>
Severity: normal CC: ionen, sam
Priority: Normal Keywords: PATCH
Version: unspecified   
Hardware: All   
OS: Linux   
Package list:
Runtime testing required: ---
Attachments: neon.patch

Description David Michael 2021-01-21 19:20:17 UTC
Building for ARM chips without NEON fails.

Reproducible: Always

Steps to Reproduce:
1. armv5tel-gentoo-linux-gnueabi-emerge -v libgcrypt

Actual Results:  
/usr/libexec/gcc/armv5tel-gentoo-linux-gnueabi/ld: ./.libs/ undefined reference to `_gcry_sha512_transform_armv7_neon'
collect2: error: ld returned 1 exit status

Expected Results:  
It should build and install.

I sent the attached patch upstream to fix the issue.  It would need to be backported.  However, I think the ebuild could probably also add the CPU USE flag to disable building optional NEON support, since this CPU will never use NEON.  The configure summary has the following when the option is not specified.

        Try using ARM NEON:        yes

This ebuild change fixes that.

--- dev-libs/libgcrypt/libgcrypt-1.9.0.ebuild
+++ dev-libs/libgcrypt/libgcrypt-1.9.0.ebuild
@@ -12,7 +12,7 @@
 SLOT="0/20" # subslot = soname major version
 KEYWORDS="~alpha amd64 arm arm64 ~hppa ~ia64 ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc x86 ~amd64-linux ~x86-linux ~ppc-macos ~x64-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris"
-IUSE="doc o-flag-munging static-libs"
+IUSE="cpu_flags_arm_neon doc o-flag-munging static-libs"
@@ -55,6 +55,8 @@
 		$([[ ${CHOST} == *86*-darwin* ]] && echo "--disable-asm")
 		$([[ ${CHOST} == sparcv9-*-solaris* ]] && echo "--disable-asm")
+		$(use_enable cpu_flags_arm_neon neon-support)
 	ECONF_SOURCE="${S}" econf "${myeconfargs[@]}" \
Comment 1 David Michael 2021-01-21 19:20:33 UTC
Created attachment 684049 [details, diff]
Comment 2 Gordon Bos 2021-01-26 12:49:37 UTC
Thanks. Ran into this today. Devs appear to have added a somewhat shorter USE flag to control this. Compiling with USE="-asm" allowed libgcrypt to complete.
Comment 3 David Michael 2021-01-26 19:46:14 UTC
Upstream has pushed the fix commit, and they are working on a 1.9.1 release with it.
Comment 4 Larry the Git Cow gentoo-dev 2021-01-29 13:19:12 UTC
The bug has been closed via the following commit(s):

commit d554d368f2cc68c944b92c2a64be391ca272eac1
Author:     Sam James <>
AuthorDate: 2021-01-29 13:10:07 +0000
Commit:     Sam James <>
CommitDate: 2021-01-29 13:10:07 +0000

    dev-libs/libgcrypt: (security) bump to 1.9.1
    This includes a critical security fix on 1.9.0 (currently masked).
    Note that the mask on 1.9.0 currently forces a downgrade
    to the safe 1.8.x series.
    Package-Manager: Portage-3.0.14, Repoman-3.0.2
    Signed-off-by: Sam James <>

 dev-libs/libgcrypt/Manifest                                          | 2 +-
 .../libgcrypt/{libgcrypt-1.9.0.ebuild => libgcrypt-1.9.1.ebuild}     | 5 +++--
 2 files changed, 4 insertions(+), 3 deletions(-)
Comment 5 Larry the Git Cow gentoo-dev 2021-01-29 14:36:44 UTC
The bug has been referenced in the following commit(s):

commit ec99bdb5626bdd50340702243b3e62fe8fd4d6bc
Author:     Sam James <>
AuthorDate: 2021-01-29 14:36:38 +0000
Commit:     Sam James <>
CommitDate: 2021-01-29 14:36:41 +0000

    dev-libs/libgcrypt: add CPU_FLAGS_*
    Package-Manager: Portage-3.0.14, Repoman-3.0.2
    Signed-off-by: Sam James <>

 dev-libs/libgcrypt/libgcrypt-1.9.1.ebuild | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)