There are a few SIMD-related issues with the newly stabilized version. First, since WITH_SIMD is enabled by default and not disabled by the ebuild, it can't build for non-NEON ARM CPUs anymore. > FAILED: simd/CMakeFiles/simd.dir/arm/jcsample-neon.c.o > /usr/bin/armv5tel-gentoo-linux-gnueabi-gcc -I. -I/var/tmp/portage/media-libs/libjpeg-turbo-2.1.0-r1/work/libjpeg-turbo-2.1.0 -Isimd/arm -O2 -pipe -ggdb -flto -mcpu=arm926ej-s -ftree-vectorize -fPIC -mfpu=neon -MD -MT simd/CMakeFiles/simd.dir/arm/jcsample-neon.c.o -MF simd/CMakeFiles/simd.dir/arm/jcsample-neon.c.o.d -o simd/CMakeFiles/simd.dir/arm/jcsample-neon.c.o -c /var/tmp/portage/media-libs/libjpeg-turbo-2.1.0-r1/work/libjpeg-turbo-2.1.0/simd/arm/jcsample-neon.c > In file included from /var/tmp/portage/media-libs/libjpeg-turbo-2.1.0-r1/work/libjpeg-turbo-2.1.0/simd/arm/jcsample-neon.c:32: > /usr/lib/gcc/armv5tel-gentoo-linux-gnueabi/10.2.0/include/arm_neon.h:31:2: error: #error "NEON intrinsics not available with the soft-float ABI. Please use -mfloat-abi=softfp or -mfloat-abi=hard" Then it supports setting the elfx32 assembler format, and it looks like SIMD builds fine for x32 now, so it doesn't need to be forcibly disabled on that ABI anymore. And it was selecting an assembler based on which cross-compiled packages are installed, not the programs that will actually be executable.
Created attachment 712203 [details, diff] fix.patch
I got the same error on my armv5tel.
Adding all these redundant cpu flags to control a single build option seems absurd to me. Why not just add a "simd" USE flag?
Because I don't see precedent for doing that elsewhere, and using CPU flags should work correctly based off users' existing settings. And https://github.com/gentoo/gentoo/blob/master/media-libs/opus/opus-1.3.1-r2.ebuild#L37
Unless there's a very good reason to disable SIMD, you should just enable it based on CFLAGS.
"Fails to compile when enabled" is a good reason to disable it. What CFLAGS are useful to test? Something common like CFLAGS="-O2 -pipe" applies to both x86_64 (where SIMD should be enabled for SSE2) and armv5 (where SIMD needs to be disabled due to no NEON).
The code should really check for respective CPU features defines, e.g. #if defined(__SSE2__) and so on.
It looks like the build system passes -mfpu=neon when compiling the relevant source files to enable the necessary intrinsic functions. This apparently causes an ABI conflict for some ARM toolchains. It definitely seems like there should be a better way to fix this, but I think a USE flag check of some sort is an okay workaround. Since the only reported problem is on ARM, maybe it makes sense to leave ppc and x86 as-is? They probably don't suffer from the same weird ABI issues that ARM does.
Created attachment 712779 [details, diff] fix.patch
Patch works for me
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4d3ec052f5c1dccdcb944d92825ea6f6fbd6325d commit 4d3ec052f5c1dccdcb944d92825ea6f6fbd6325d Author: David Michael <fedora.dm0@gmail.com> AuthorDate: 2021-05-29 13:01:23 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2021-06-04 15:04:34 +0000 media-libs/libjpeg-turbo: fix SIMD issues This adds a NEON CPU flag to disable SIMD on ARM CPUs without NEON, which avoids ABI-related build failures. This also drops the obsolete x32 workaround, and it fixes assembler package detection to use BROOT. Closes: https://bugs.gentoo.org/792810 Package-Manager: Portage-3.0.18, Repoman-3.0.2 Signed-off-by: David Michael <fedora.dm0@gmail.com> (made the 'if's more verbose) Signed-off-by: Michał Górny <mgorny@gentoo.org> .../libjpeg-turbo/libjpeg-turbo-2.1.0-r2.ebuild | 128 +++++++++++++++++++++ 1 file changed, 128 insertions(+)
*** Bug 794937 has been marked as a duplicate of this bug. ***
