Created attachment 643834 [details] build.log with neon disabled It seems like libaom changed the handling of neon (and potentially has a bug in their config?). Here's the build with cpu_flags_arm_neon disabled, as it is currently masked for this package on arm64 FAILED: CMakeFiles/aom_rtcd.dir/av1/common/av1_rtcd.c.o In file included from ../av1/common/av1_rtcd.c:14: ./config/av1_rtcd.h: In function ‘setup_rtcd_internal’: ./config/av1_rtcd.h:524:40: error: ‘av1_apply_selfguided_restoration_neon’ undeclared (first use in this function); did you mean ‘av1_apply_selfguided_restoration_c’? 524 | av1_apply_selfguided_restoration = av1_apply_selfguided_restoration_neon; | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | av1_apply_selfguided_restoration_c and a dozen more of undeclared uses related to neon. Unmasking cpu_flags_arm_neon and enabling it builds the package fine. Out of curiosity I also tried libaom-1.0.0-r2 with neon, which also compiled fine. I think the flag can be unmasked for this package on arm64. Attached is the build.log with cpu_flags_arm_neon disabled
ebuilds shouldn't be using cpu_flags_arm_neon to turn on neon on arm64; they should do that based on it being arm64. cpu_flags_arm_neon is only for 32bit arm. If libaom ENABLE_NEON knob works on 64bit, it should just be enabled unconditionally if arm64, with something like -DENABLE_NEON=$(usex arm64 ON $(usex cpu_flags_arm_neon ON OFF)) (didn't test)
The bug is uncovered because the arm64 profile not hard enabling neon (as it should) while the build system assumes that. The arch team should not hard-disable neon.
This should address it, upstream libaom should be notified, but it is as strange as hard-disabling sse on amd64. diff --git a/profiles/arch/arm64/use.force b/profiles/arch/arm64/use.force index 9747410d041..ad4cb1b4c75 100644 --- a/profiles/arch/arm64/use.force +++ b/profiles/arch/arm64/use.force @@ -9,6 +9,7 @@ cpu_flags_arm_v7 cpu_flags_arm_v8 cpu_flags_arm_edsp +cpu_flags_arm_neon cpu_flags_arm_thumb cpu_flags_arm_thumb2 cpu_flags_arm_vfp diff --git a/profiles/arch/arm64/use.mask b/profiles/arch/arm64/use.mask index e58c0bcf118..ed5c44fc41f 100644 --- a/profiles/arch/arm64/use.mask +++ b/profiles/arch/arm64/use.mask @@ -8,11 +8,6 @@ # Mono is hopelessly broken on arm64 mono -# Aaron Bauman <bman@gentoo.org> (2019-12-27) -# Mask cpu_flags_arm_neon for all of arm64 -# A neon64 USE is being discussed -cpu_flags_arm_neon - # Unmask arm specific USE flags -cpu_flags_arm_v4 -cpu_flags_arm_v4 @@ -24,6 +19,7 @@ cpu_flags_arm_neon -cpu_flags_arm_aes -cpu_flags_arm_crc32 -cpu_flags_arm_edsp +-cpu_flags_arm_neon -cpu_flags_arm_sha1 -cpu_flags_arm_sha2 -cpu_flags_arm_thumb
NAK. We are not and should NOT hard-enable cpu_flags_arm_neon. Neon on arm and aarch64 is a bit different and various packages fail to build if cpu_flags_arm_neon is forced on them on a arm64 system. As I explained in my previous comment and on IRC, arm64 compatible neon should just be unconditionally enabled if use arm64.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=547d360604c083a21e7168d904506e055452d74f commit 547d360604c083a21e7168d904506e055452d74f Author: Luca Barbato <lu_zero@gentoo.org> AuthorDate: 2020-06-09 14:04:39 +0000 Commit: Luca Barbato <lu_zero@gentoo.org> CommitDate: 2020-06-09 14:05:28 +0000 media-libs/libaom: Force neon on arm64 Fixes: https://bugs.gentoo.org/727432 Thanks to leio for the fix. Package-Manager: Portage-2.3.100, Repoman-2.3.22 Signed-off-by: Luca Barbato <lu_zero@gentoo.org> media-libs/libaom/libaom-2.0.0.ebuild | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
