media-libs/flac-1.3.2-r1 uses the below line to pass --enable-sse or --disable-sse to the configure script: $(use_enable cpu_flags_x86_sse sse) Unfortunately, --enable-sse actually means "enable SSE2" rather than "enable SSE1". The resulting binary crashes with SIGILL on a Pentium3 (CPU_FLAGS_X86="mmx mmxext sse"). Reproducible: Always
Created attachment 563758 [details, diff] patch for flac-1.3.2-r1.ebuild
I'm seeing this same bug now within dev-lang/rust. Requirement, cpu_flags_x86_sse2. And yet, building dev-lang/rust on platforms without sse2 is possible by using <= i586 archs/platforms. (eg. CFLAGS -march i586) The bug reporter's patch merrily disables sse2, substituting with sse instruction set. And I'm not sure that's proper unless you look at the code or ask the flac package maintainers proper build requisites. This bug appears more indepth into portage, with somebody hard-coding (aka hacking) the code only to accept SSE2. A more proper method is to check CPU flags, and finding-out what the target package compile requires when building and executing upon SSE or SSE2 platforms. For dev-lang/rust, from my brief research on the Internet, simply specifying "CFLAGS -march i586" will build the dev-lang/rust package without SSE2. Specifying "CFLAGS -march i686" (or "CFLAGS -march pentium3" in my case, even though I do not have a SSE2 CPU), will enable building with SSE2 instructions. I could then work around this by using "/etc/portage/package.env" and adding a "dev-lang/rust i586.conf" setup, bypassing SSE2 requisite. The best work around or coding practice is likely to obey a person's configured CPU_FLAGS_X86, and not to enforce such restrictions for a substitution for proper research into packages' build requisites. Doing a quick search on the Internet for "rust sse2" will readily show recent fixes to avert and recent fixes to side-step the SSE2 instruction set.
For my pentium3 CPU platform without SSE2 and only SSE, I modified the (dev-lang/rust) ebuild for substituting sse for sse2, and created the /etc/portage/portage.env entry "CFLAGS -march=i586". (See how to setup /etc/portage/portage.env for controlling CFLAG on an individual package basis.) I'll likely need to test the dev-lang/rust binaries prior to continuing to build seamonkey.
(In reply to Roger from comment #3) > For my pentium3 CPU platform without SSE2 and only SSE, I modified the > (dev-lang/rust) ebuild for substituting sse for sse2, and created the > /etc/portage/portage.env entry "CFLAGS -march=i586". (See how to setup > /etc/portage/portage.env for controlling CFLAG on an individual package > basis.) > > I'll likely need to test the dev-lang/rust binaries prior to continuing to > build seamonkey. I'm having the same problem on a freshly downloaded i486 stage3, with -march=i486 and CHOST="i486-pc-linux-gnu" At the first emerge @world, dev-lang/rust demanded SSE2 so it didn't start compiling at all. I moved the hard drive to a different, faster computer than the one where I want to run Gentoo. This one has SSE2 and it started compiling after I declared the correct CPU_FLAGS_X86 in make.conf for that processor, but I could see it pulling in sources and setting targets with i686 in the name. Aborted compilation, ran "portageq envvar CHOST_x86" and voila, it reported i686-pc-linux-gnu. This is easily fixed by specifically declaring CHOST_x86="i486-pc-linux-gnu" in make.conf so I did that, then restarted emerge @world adding --changed-use to the usual command. I also tried to comment the CPU_FLAGS_X86 line where sse2 was declared, but again it refused to start because rust demands SSE2. I can now finish the installation, but who knows if the install will still work on the old machine...
I just so happen to have a machine with two Pentium 3 Tualatin-S CPUs running Gentoo and I've hit this bug. Setting USE=cpu_flags_x86_sse will make the configure script prepare a Makefile that has -msse2 all over it. Attaching logs.
Created attachment 685233 [details] build.log of media-libs/flac-1.3.3-r1 with USE=cpu_flags_x86_sse on i686 This build log will land in "temp" directory of the package's Portage workspace upon compiling the source of media-libs/flac-1.3.3-r1 with USE=cpu_flags_x86_sse
(In reply to Michał Dec from comment #6) > Created attachment 685233 [details] > build.log of media-libs/flac-1.3.3-r1 with USE=cpu_flags_x86_sse on i686 > > This build log will land in "temp" directory of the package's Portage > workspace upon compiling the source of media-libs/flac-1.3.3-r1 with > USE=cpu_flags_x86_sse It seems that during configure stage, there lies the culprit: > checking if i686-pc-linux-gnu-gcc accepts -msse2... yes Further checking: Kars /var/tmp/portage/media-libs/flac-1.3.3-r1/work/flac-1.3.3 # grep msse2 . -r ./configure: --disable-sse Disable passing of -msse2 to the compiler ./configure: { $as_echo "$as_me:${as_lineno-$LINENO}: checking if $CC accepts -msse2" >&5 ./configure:$as_echo_n "checking if $CC accepts -msse2... " >&6; } ./configure: CFLAGS="-msse2" ./configure: CFLAGS="$ac_add_cflags__old_cflags -msse2" ./configure.ac:AC_HELP_STRING([--disable-sse], [Disable passing of -msse2 to the compiler]), ./configure.ac: XIPH_ADD_CFLAGS([-msse2]) Foolish to presume that just because the compiler accepts an option, it must be enabled. Can't wait to do AVX2 on my Pentium 3 :) This is a bug in upstream of libFLAC.
Enabling SSE2 optimizations on a CPU only capable of SSE will cause significant problems. Has been a big problem on my Pentium3 SSE only platforms or non-sse2 platforms! Somebody may have accidentally hard-coded something? Or maybe you only enabled CPU_FLAGS_X86="sse" assuming this would also enable sse2? If so, you should have something like, "CPU_FLAGS_X86="sse sse2"
(In reply to Roger from comment #8) > Enabling SSE2 optimizations on a CPU only capable of SSE will cause > significant problems. Has been a big problem on my Pentium3 SSE only > platforms or non-sse2 platforms! > > Somebody may have accidentally hard-coded something? > > Or maybe you only enabled CPU_FLAGS_X86="sse" assuming this would also > enable sse2? If so, you should have something like, "CPU_FLAGS_X86="sse > sse2" Enabling sse2 on a Pentium 3? Why would I do that? No. I have globally enabled everything that cpuid2cpuflags enables, which for Pentium 3 Tualatin-S in my case is mmx, mmxext and sse. media-libs/flac doesn't even offer sse2 as a CPU_FLAGS_X86 flag - this bug simply put means that emerging media-libs/flac with CPU_FLAGS_X86="sse" will cause the configure script from libflac's source directory to be called with --enable-sse, which demonstrably due to a bug in this script, also enables sse2 - in comment 7 I have shown that this flag, intended for sse, as in sse without any numbers, by their mistake enables sse2.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ac8f78e4e709a03b3afa571bb9af445cd6473231 commit ac8f78e4e709a03b3afa571bb9af445cd6473231 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-09-25 03:51:36 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-25 03:51:36 +0000 media-libs/flac: add 1.4.1 Closes: https://bugs.gentoo.org/677274 Signed-off-by: Sam James <sam@gentoo.org> media-libs/flac/Manifest | 1 + media-libs/flac/flac-1.4.1.ebuild | 65 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 66 insertions(+)
