Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 677274 - media-libs/flac-1.3.2-r1 CPU_FLAGS_X86=sse should not enable SSE2 support
Summary: media-libs/flac-1.3.2-r1 CPU_FLAGS_X86=sse should not enable SSE2 support
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: x86 Linux
: Normal normal (vote)
Assignee: Gentoo Sound Team
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2019-02-04 18:59 UTC by Will Simoneau
Modified: 2021-02-07 04:23 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
patch for flac-1.3.2-r1.ebuild (flac-1.3.2-r1-sse2.patch,886 bytes, patch)
2019-02-04 19:02 UTC, Will Simoneau
Details | Diff
build.log of media-libs/flac-1.3.3-r1 with USE=cpu_flags_x86_sse on i686 (build.log.xz,7.61 KB, application/x-xz)
2021-01-31 01:03 UTC, Michał Dec
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Will Simoneau 2019-02-04 18:59:11 UTC
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
Comment 1 Will Simoneau 2019-02-04 19:02:01 UTC
Created attachment 563758 [details, diff]
patch for flac-1.3.2-r1.ebuild
Comment 2 Roger 2020-05-15 00:47:53 UTC
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.
Comment 3 Roger 2020-05-15 01:12:28 UTC
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.
Comment 4 subzero_ro 2020-09-20 10:18:16 UTC
(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...
Comment 5 Michał Dec 2021-01-31 00:59:25 UTC
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.
Comment 6 Michał Dec 2021-01-31 01:03:23 UTC
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
Comment 7 Michał Dec 2021-01-31 01:27:00 UTC
(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.
Comment 8 Roger 2021-02-01 04:46:19 UTC
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"
Comment 9 Michał Dec 2021-02-07 03:48:11 UTC
(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.