Distributions Falsely Advertising <= i686/Pentium3 support, or CPUs without SSE2!
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
SSE2 is not enabled by default by GCC when compiling with -march=i686. It would seem that the build scripts for some 32-bit Slackware packages explicitly enable SSE2, which technically makes them incompatible with "i686" (even though the package name is "<something>-<version>-i686-<revision>.tgz").
So it might be, but looking at the build script at http://ftp.slackware.com/pub/slackwa...peg.SlackBuild
you can see that the 32 bit Slackware package for i586 architecture was supposed to be built with the flags "-O2 -march=i586 -mtune=i686"
I can find no SSE flags in that build script.
If this still gives an illegal instruction on any i686 it would either mean that the ffmpeg configure script has failed to listen to the CFLAGS or that ffmpeg is using some library that was not built to work on an i586. One third possibility would be if the original poster installed ffmpeg from some other source than the original Slackware package.
If this still gives an illegal instruction on any i686 it would either mean that the ffmpeg configure script has failed to listen to the CFLAGS or that ffmpeg is using some library that was not built to work on an i586.
It does give an illegal instruction error on non-SSE2 systems, but the build script does indeed look correct.
Which leaves one possibility: One of the included libraries are to blame, and they are legion. Unless someone knows a quick way to determine whether a library contains SSE2 instructions, it'll take me a while to chase that down. Edit: Ignore that, I'm an idiot. All I need to do is enable coredumps and use gdb.
Quote:
Originally Posted by henca
One third possibility would be if the original poster installed ffmpeg from some other source than the original Slackware package.
I've tested using only Slackware 15.0 packages, and:
strace shows that the last operations before SIGILL were related to libgcrypt. Not sure why ffmpeg would need that, but it is indeed linked for some reason.
strace shows that the last operations before SIGILL were related to libgcrypt.
Again, the SlackBuild script for the i586 package at http://ftp.slackware.com/pub/slackwa...ypt.SlackBuild
does not seem to intentionally build with flags that requires any SSE. The CFLAGS are again set to "-O2 -march=i586 -mtune=i686", but maybe the internal configure script of libgcrypt or any internal Makefile in libgcrypt forces the use of SSE2.
While I did find some questionable autodetection in the libgcrypt ./configure script, which really should be explicitly disabled to avoid picking up specific features from the build system (padlock, for instance), there was no SSE2 issue:
Code:
checking whether padlock support is requested... yes
checking whether AESNI support is requested... yes
checking whether SHAEXT support is requested... yes
checking whether PCLMUL support is requested... yes
checking whether SSE4.1 support is requested... yes
checking whether DRNG support is requested... yes
checking whether AVX support is requested... yes
checking whether AVX2 support is requested... yes
checking whether NEON support is requested... yes
checking whether ARMv8 Crypto Extension support is requested... yes
checking whether PPC crypto support is requested... yes
But I ran a quick gdb session against a coredump from ffmpeg, and I think we have a winner: The libopenal.so.1 library, part of the openal-soft package.
Looking at the source, it's using cmake, which has been a constant headache for me whenever I create build scripts for 3rd party software.
During the (Slack)build process, which I'm running on a decidedly non-SSE2, 32-bit system, I get this:
Code:
-- Performing Test HAVE_MSSE2_SWITCH
-- Performing Test HAVE_MSSE2_SWITCH - Success
<--- cut --->
-- Performing Test HAVE_MFPMATH_SSE_2
-- Performing Test HAVE_MFPMATH_SSE_2 - Success
<--- cut --->
Building with support for CPU extensions:
Default, SSE, SSE2, SSE3, SSE4.1
-- Building with SSE2 codegen
...which seems to suggest that it won't even run on the system on which I'm currently doing the build. Odd.
Last edited by Ser Olmy; 05-22-2022 at 01:28 PM.
Reason: include libgcrypt ./configure log excerpt
And sure enough, the libopenal.so.1 library from the openal-soft package I just created on an old Pentium III system without SSE2, causes an "illegal instruction" exception (SIGILL) on that very same system.
Looking at CMakeLists.txt, it seems the script enables SSE2 all on its own.
And sure enough, the libopenal.so.1 library from the openal-soft package I just created on an old Pentium III system without SSE2, causes an "illegal instruction" exception (SIGILL) on that very same system.
Looking at CMakeLists.txt, it seems the script enables SSE2 all on its own.
One important thing to note about this release is that 32-bit x86 builds
now rely on SSE2 by default (the compiler is set to generate SSE1 and
SSE2 opcodes for floating-point math). This makes SSE2 required, even if
it's disabled via the config option. The vast majority of processors
released in the last 10+ years should have no problem with this. This
was done for performance reasons, since SSE has the capability to more
efficiently deal with denormal floating-point numbers that occur with
various DSP stages, which normally severely hamper performance on x87
units. There are build-time options to disable this behavior and revert
to x87 (or x87+SSE1-only) codegen if desired, but the recommendation is
to leave it as SSE2 unless you really need otherwise.
There are build-time options to disable this behavior and revert
to x87 (or x87+SSE1-only) codegen if desired, but the recommendation is
to leave it as SSE2 unless you really need otherwise.
And since we really need otherwise, I'll just have to find the cmake
So, to honor the functionality on some chimerical obsolete systems, we should curse every user of Slackware 32bit with slow, inefficient packages?
Please do not give the argument of Third World - it's not realist.
Working as geologist, I had been in Africa, I have seen the villages in savanna - there the biggest problem is the electrical power, because there is no electrical grid.
That's why there the kids eventually, IF they are lucky, they are rocking ARM Android tablets or Linux ARM boards powered with solar panels, NOT your older than dirt hardware crap.
For them, a Raspberry Pi or a Whatever PI is much more interesting than an antic Pentium III - because eventually they can power up that ARM board.
Heck, for my really huge surprise I've even seen invented batteries working in fruits juice!
Last edited by LuckyCyborg; 05-22-2022 at 02:56 PM.
So, to honor the functionality on some chimerical obsolete systems, we should curse every user
So tell us, are you running a very fast 32-bit only x86 system?
Will you be negatively affected if the openai-soft package starts supporting i586 as it says in the package name? You know, like it did in Slackware 14.2? Prior to the change announced with the release of OpenAL Soft 1.19.0?
No? Then what are you on about?
The OP has a non-SSE2 x86 system, and apparently wants to run ffmpeg. He should be able to do so.
I manage multiple non-SSE2 x86 systems, but they're mostly headless appliances that don't ever need to run ffmpeg. That doesn't mean I get to ignore anybody who's not me, and have different needs.
Of course, if by random chance there's someone out there who really needs the fastest ffmpeg on their 32-bit x86 system, I'd be more than happy to help them build an i686_SSE2 package.
But an i586 package should be, well, an i586 package. IMNSHO.
I added these to the SlackBuild script, and now ffmpeg works again.
Just one final comment regarding the OpenAL Soft 1.19.0 release announcement:
Quote:
Originally Posted by https://openal.org/pipermail/openal/2018-September/000714.html
One important thing to note about this release is that 32-bit x86 builds now rely on SSE2 by default (the compiler is set to generate SSE1 and SSE2 opcodes for floating-point math). This makes SSE2 required, even if it's disabled via the config option.
So manually disabling SSE2 means SSE2 will still be enabled, unless double-disabled by another, undocumented switch. That's just asinine.
And really, GCC should just refuse to compile anything when both -march=i586 and -msse2 are specified, as you'll be compiling for the esoteric "i586 CPU with SSE2 support", which has obviously never existed.
So tell us, are you running a very fast 32-bit only x86 system?
Will you be negatively affected if the openai-soft package starts supporting i586 as it says in the package name? You know, like it did in Slackware 14.2? Prior to the change announced with the release of OpenAL Soft 1.19.0?
No? Then what are you on about?
Buddy, the OpenAL(-soft) was added to Slackware in Feb 15 2020 along with Qt5 - most probably as dependency of the (incoming) Plasma 5, because it was before present in KTown.
This particular package was NEVER supported officially before. It was NEVER supported officially for Slackware 14.2 or any previous release.
Code:
Sat Feb 15 02:42:28 UTC 2020
a/kernel-generic-5.4.20-x86_64-1.txz: Upgraded.
a/kernel-huge-5.4.20-x86_64-1.txz: Upgraded.
a/kernel-modules-5.4.20-x86_64-1.txz: Upgraded.
a/shadow-4.8.1-x86_64-3.txz: Rebuilt.
a/util-linux-2.35.1-x86_64-3.txz: Rebuilt.
d/kernel-headers-5.4.20-x86-1.txz: Upgraded.
k/kernel-source-5.4.20-noarch-1.txz: Upgraded.
l/ConsoleKit2-1.2.1-x86_64-2.txz: Rebuilt.
l/dconf-editor-3.34.4-x86_64-1.txz: Upgraded.
l/libxkbcommon-0.10.0-x86_64-1.txz: Added.
l/openal-soft-1.19.1-x86_64-1.txz: Added.
l/qt5-5.13.2-x86_64-1.txz: Added.
Thanks to alienBOB.
n/openssh-8.2p1-x86_64-1.txz: Upgraded.
Potentially incompatible changes:
* ssh(1), sshd(8): the removal of "ssh-rsa" from the accepted
CASignatureAlgorithms list.
* ssh(1), sshd(8): this release removes diffie-hellman-group14-sha1
from the default key exchange proposal for both the client and
server.
* ssh-keygen(1): the command-line options related to the generation
and screening of safe prime numbers used by the
diffie-hellman-group-exchange-* key exchange algorithms have
changed. Most options have been folded under the -O flag.
* sshd(8): the sshd listener process title visible to ps(1) has
changed to include information about the number of connections that
are currently attempting authentication and the limits configured
by MaxStartups.
x/mesa-19.3.4-x86_64-2.txz: Rebuilt.
Reverted "[PATCH] swr: Fix GCC 4.9 checks." which makes X fail to start with
an illegal instruction on some hardware.
isolinux/initrd.img: Rebuilt.
kernels/*: Upgraded.
testing/packages/PAM/ConsoleKit2-1.2.1-x86_64-2_pam.txz: Rebuilt.
Rebuilt with --disable-libcgmanager to fix setting limits on PAM.
Thanks to gattocarlo.
testing/packages/PAM/openssh-8.2p1-x86_64-1_pam.txz: Upgraded.
testing/packages/PAM/shadow-4.8.1-x86_64-3_pam.txz: Rebuilt.
Moved some of the /etc/pam.d/ file to the util-linux package where they
more properly belong.
testing/packages/PAM/util-linux-2.35.1-x86_64-3_pam.txz: Rebuilt.
Added some /etc/pam.d/ files previously in the shadow package.
Changed /etc/pam.d/{chfn,chsh} and made chfn/chsh setuid root to fix them.
Added /etc/pam.d/{runuser,runuser-l}.
usb-and-pxe-installers/usbboot.img: Rebuilt.
Anyway, my honest opinion is that the real hardware using non-SSE2 CPUs is so old that technically you cannot efficiently run a modern operating system - including there the Slackware 15.0 or even install it.
What the heck you do today with a box having 64MB memory, 1GB storage (if not 250MB) and a S3 Virge as video card? This is the typical hardware around a non-SSE2 CPU.
I for one, I believe that simply we should accept that SSE2 is required and that's all.
And yes, I have pure 32 bit systems - I have a Pentium 4 box, with socket 775 and 4 GB memory and a 160GB hard drive using SATA.
Last edited by LuckyCyborg; 05-22-2022 at 03:22 PM.
Buddy, the OpenAL(-soft) was added to Slackware in Feb 15 2020 along with Qt5 - most probably as dependency of the (incoming) Plasma 5, because it was before present in KTown.
I know. There was a SlackBuild for it, one that worked very well under Slackware 14.2.
Quote:
Originally Posted by LuckyCyborg
Anyway, my honest opinion is that the real hardware using non-SSE2 CPUs is so old that technically you cannot efficiently run a modern operating system - including there the Slackware 15.0 or even install it.
That does indeed seem to be your opinion. I'm not so sure about the rationality of it, though, since:
Quote:
Originally Posted by LuckyCyborg
What the heck you do today with a box having 64MB memory, 1GB storage (if not 250MB) and a S3 Virge as video card? This is the typical hardware around a non-SSE2 CPU.
No, it's not.
You seem to have absolutely no idea what you're talking about (in this regard), and I think it would be beneficial to all if you would be kind enough to stop derailing the thread.
I've been working with OpenAL-soft and use it in several places, including other operating systems. When I updated these dependencies recently, I noticed, not only did they break backwards compatibility for CPU as mentioned here in the recent update, but also for OS by their changes for high resolution timers. OpenAL has been around a long time, since ~2000 when no one was optimizing for SSE2 in this way. There are plenty of old games that use it and can continue to work with these old P2/P3 or even older. What benefit does anyone get by forcing this change, breaking things? It's definitely not a performance benefit here, because there is absolutely no need for it.
The correct thing to do is do a CPU detection at initialization or even extend the API to configure SSE usage. There are reasons not to use SSE sometimes, and the old way can be preferred on modern CPU. Speaking of ffmpeg/mplayer, I think they do configure their optimizations at runtime, that was how they used to produce binaries that worked on say i486 so distros could package for all 32-bit systems, but run much faster with optimizations for newer CPU without recompilation. At least that was how you used to do it. That wouldn't work if there is a dependent library not following these design patterns (say libgcrypt) but that doesn't surprise me lately. More or less GCC is preferring SSE on x86_64. I can't say what it is doing on i586 if it makes sense.
Last edited by the3dfxdude; 05-22-2022 at 04:28 PM.
After briefly scanning some of the responses, ditto with what Ser Olmy has stated!
Kernel CPU architecture specifications/options and compiler (eg. GCC, CFLAGS, CXXFLAGS, ...) settings are two separate items, or more specifically; the kernel object/payload and compiled packages are two separate areas CPU optimizations can be selected!
Recent Slackware will boot and execute on my Pentium 3 non-SSE2 laptop, up until a package compiled with SSE2 CPU instructions is executed.
The rust programming language is a big sponsor of quietly dropping SSE in favor of only supporting SSE2 CPUs. The rust language has recently been pulled into, as a dependency, on one or a few low-level base packages recently. (Forgive me, I cannot recall the package names, however the more popular FFmpeg optional package has an option to pull in rust as a dependency.)
On my initial post, I should have clarified this a little bit more, rather than just stating to test by running a package such as FFmpeg. On the flip, assumed only people concerned or understanding the post would be programmers.
Thanks Ser Olmy for further clarifying, and remember, if code doesn't use SSE2 instructions within it's source code, even if SSE2 is specified as a compile time optimization, an illegal instruction will not occur with the CPU until code is executed using the CPU SSE2 register. So for example, the common base program "ls" likely does not contian source code using the CPU SSE2 register, so even if the "ls" source code is compiled with SSE2 compiler optimizations, the program "ls" should still execute just fine on a non-SSE2 CPU. So it is more likely, in my experience, compiler (eg. CFLAGS/CXXFLAGS) are usually bulk applied to all programs, unless a distribution has a list of packages of using different CFLAGS/CXXFLAGS.
Cr*p, I see a second page of responses, I'll have to scan through those later.
Again, thanks for getting this thread back on track.
(Just scanned through the second page of responses here.)
Ser Olmy: You rock. Wow, surprised the debugger pulled OpenAl as the culprit! (I was assuming Rust again.) Alpine's ffmpeg currently runs just fine, though no idea if it's pulling in OpenAL or what versions.
However, it maybe only time that SSE2 will become the norm. I also have no idea of the number of poor people, whom are programmers or happen to run non-SSE2 platforms. Could be just currently me & Ser Olmy within the entire world still running non-SSE2 archs, but with the Reddit post referenced within my initial post, likely many others -- likely people without lots of money -- still trying to use their older non-SSE2 platforms and with the post being subsequently locked from further replies... shrugs. Also, Linux, Slackware; have always been known to just work for many older platforms. Think one of the main reasons, for historical archiving of software.
I for one, enjoy maintaining my older working non-SSE2 Pentium 3, back in the day, $1,000+, platforms.
I also use, at most, DWM window manager. For most of my tasks, I do just fine via the console. So FFmpeg provides FFplay for playing audio media, without using X/Xorg. (Other more prominent terminal based media players, mpg123, mpv, mplayer...) One my tasks for some of my older non-SSE2 platforms, possibly using as a garage media player.
Wondering, maybe a good idea to start a fresh new SSE2 thread, for logging SSE2 inclusion problems, agnostic from politics. (eg. Bug.) On the flip, since I'm just a user (and do not get much time for whipping-out cc/strace/gdb), I'll understand if Slackware goes all SSE2.
Again, thanks Ser Olmy for your time and whipping-out the debugger on this.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
