media-libs/embree for arm64 requires "neon" - https://bugs.gentoo.org/851705 # emerge embree -pvq [ebuild R ] media-libs/embree-3.13.5 USE="compact-polys raymask ssp tbb -ispc -tutorial" CPU_FLAGS_ARM="neon"
i have to add: media-libs/embree -cpu_flags_arm_neon to /etc/portage/profile/package.use.mask for package to build
To the arm64 maintainers: Is there any specific reason why the neon flag is masked in the arm64 use.mask? The file only has this comment which is three years old at this point: # 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 I don't have an ARM CPU, so I can't really test any of this. But to me I don't see any reason for this besides maybe that support for neon was flaky for the arm64 at some point (or perhaps still is). But as I didn't find any information about this, I just have to assume that it might be time to remove the flag mask instead of having a white list of packages.
(In reply to Sebastian Parborg from comment #2) > To the arm64 maintainers: > > Is there any specific reason why the neon flag is masked in the arm64 > use.mask? > > The file only has this comment which is three years old at this point: > # 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 > > I don't have an ARM CPU, so I can't really test any of this. But to me I > don't see any reason for this besides maybe that support for neon was flaky > for the arm64 at some point (or perhaps still is). But as I didn't find any > information about this, I just have to assume that it might be time to > remove the flag mask instead of having a white list of packages. i have gentoo on Apple M1 Max, VM on Parallels Desktop, so i can test anything for you if required
Hmm, I would have liked to get some feedback from the arm64 maintainers first. However I guess you could try to compile every package with the `neon` arm cpu flag and see if it works for you. If it does, I don't see any reason to keep the flag masked. Or if only a few fails, we can do a blacklist for the flag instead of a white list.
same for media-libs/openpgl
Just noticed the global arm64 neon mask on a different package after checking that the new version of cpuid2cpuflags still happily reports that neon should be in CPU_FLAGS_ARM. We can test things on armv8 cortex-a72.cortex-a53 big.LITTLE RK3399 based RockPro64.
