Just FTR, anyone suffering on similarly old hardware that can arrange shipping I will gladly pack up and send a working Asus Motherboard with an AMD-FX57 CPU and (IIRC) 2GB high quality OCZ RAM for free. I only have the one and I have no idea how much shipping would cost anyone interested but it doesn't weigh a lot so shouldn't be too terrible.

1 members found this post helpful.

It would be fantastic if we can identify the list of programs that force SSE2+ beyond the base arch. I have been running into this periodically with programs that were working before and suddenly do not. In terms of what I care about on slackware, would actually go back to -march=i586. The earlier point was made is how can we deal with that even, where the developer can violate that assumption without any kind of notice given. If Slackware did go all SSE2, I think then it should be set to -march=pentium4, otherwise, I still consider it an i586 distro, and some programs are buggy

Be careful what you wish! We may end with SSE2 being mandatory for entire Slackware 32bit.

Did you remember why Slackware 32bit switched from architecture of i486 to i586? No?

To refresh your memory: because some "main" programs started to malfunction while being compiled for i486 - one was Firefox, which now is already i686.

My prediction: the future of Slackware 32bit will be i786, aka i686 with SSE2.

1 members found this post helpful.

Firefox, as well as recent versions of SeaMonkey also include SSE2; and this was recent within the past couple of years. Again, directly inhibited by the Rust programming language quietly dropping SSE2 support within the past recent year(s) ... from a user perspective here.

Here's a more complete Slackware quote concerning the switch from i486 to i586:

http://slackware.osuosl.org/slackwar...gcc.SlackBuild

/* begin quote */

# Some more notes, Mon Aug 3 19:49:51 UTC 2015:
#
# Changing to -march=i586 for 32-bit x86 as several things (Mesa being one of
# them) no longer work if constrained to -march=i486. We're not going to use
# -march=i686 since the only additional opcode is CMOV, which is actually less
# efficient on modern CPUs running in 32-bit mode than the alternate i586
# instructions. No need to throw i586 CPUs under the bus (yet).

/* end quote */


From what I can recall, this too, was about the time Rust developers were talking about only supporting SSE2, but continued with a few patches for supporting older CPUs.

Not an expurt on Slackware matters, as I previously iterated, just a user.

Another reason for having a few Linux distributions supporting older hardware, is also for the older likely more stable audio/video firewire/ieee1394 hardware being used for VHS tape archiving. Albeit, PCI/PCIe hardware is apparently far superior, however somebody may only have the deprecated firewire video transfer hardware, for which is far superior than USB video methods of today, with the exception firewire/dv slightly possibly lacking in yuv color space. (There are some recent PCI/PCIe firewire hardware, however the company names are not well known, so stability maybe an issue.) As for me, even though the end of the world may come some day, I say lets try to make the best of it while we can. Most of the older likely more stable firewire hardware is only found on platforms prior to SSE2 CPUs, or Pentium 3 platforms not having SSE2. Subsequent to SSE2, firewire very quickly faded away due to everybody thinking USB 3 was better. I'm lucky to have a few dollars, and am able to afford newer PCI/PCIe hardware for analog/VHS video transfers.

Just one clarification: Rust as such does not require SSE2.

Rust is a (moderately) high-level programming language, and contains nothing that would explicitly require certain CPU extensions.

However ... the form in which the Rust source is distributed, means you need a functioning Rust compiler in order to compile the Rust compiler. Yes, Rust is a build dependency for Rust. And since the "official" Rust executable provided by the Rust project requires SSE2, you can't even create a non-SSE2 version of Rust unless your hardware supports SSE2.

It is, however, perfectly possible to build a non-SSE2 Rust executable on a system without SSE2 support, and you could then use that executable to compile future Rust versions, and so on.

Rust is not the only programming language that depends on itself in order to build; Java and Go have similar issues, but Rust is in a class all by itself since there's only one Rust compiler in existence. This means there's no way one can create a trusted executable using the official source code and tools, as you have no idea what the pre-built binary may include in the object code.

2 members found this post helpful.

So basically Pentium 4, Pentium M, and early IA32-only Atom processors? AMD didn't include SSE2 until their Athlon64 processors, so no IA-32 have it.
Believe it or not, there are actually i586 equivalent SoC still in production, albeit rare.
https://en.wikipedia.org/wiki/Vortex86#CPU
https://en.wikipedia.org/wiki/Vortex86#Vortex86DX3
My IBM T23 has similar specs, PIII 1GHz and 1GiB memory, but has SSE.

I didn't look too hard into the SSE2 instructions, but noticed things like GIMP, Firefox, Lagrange (Gemini Client), and Netsurf would not work, throwing an 'Illegal Instruction' error. Netsurf seems to not work due to using GTK+. It depends on librsvg, which is written in Rust. After upgrading the kernel on that machine, it would no longer boot (it would restart after Lilo screen) so I instead decided to try NetBSD on it, which is compiled for i486. Netsurf works on it, but those others do not.

zaphar: I found a forum post concerning the Windows Gimp compiled version dated 2016, requiring SSE3 due to one small plugin requiring SSE3. Disabling the plugin restores function to Gimp.

Thanks for fighting the good fight! Some time ago I tried to build a non-SSE2 rust so that I could build a non-SSE2 firefox/seamonkey. Based on the discussion in https://github.com/rust-lang/rust/pull/31110 I'm led to believe that building rust for an i586 host/target will do what we want (since they've co-opted "i686" to mean "modern-ish x86, roughly pentium4 +sse2" and are reluctant to change it). I lost patience trying to get rust to bootstrap successfully. This was around version 1.40, perhaps it's better now.

In that discussion there are mentions that clang may also target "pentium4" when "i686" architecture is specified, but it might not emit SSE2 instructions unless you explicitly tell it to. I don't know how true this is, it would be good to verify that clang isn't also contributing to the problem.

Found my notes. Apparently I did succeed with building a non-SSE2 rust and firefox about 2.5 years ago. I don't remember getting seamonkey working.

Patches/instructions for -current as of December 2019, likely stale by now. Pat may have made some changes to the rust and/or firefox SlackBuild scripts in response to this to make it easier.

Suspicion that clang is also emitting pentium4 and/or SSE2 instructions by default.

People, WHY did you think that Slackware 32bit should be "fixed" ? Did you even wondered IF Slackware wants to be "fixed" ?

This could be said only by Mr. Volkerding, but permit me to doubt that he will post in this thread with a title which accuse Slackware of false advertising - in fact, even it's this thread about "fixing" Slackware?

Anyway, facts are that Slackware 15.0 32bit was developed over a quite long development cycle - around 6 years.

So, permit me to doubt that Mr. Volkerding is not aware that at least partially (multimedia and graphics side at least) the SSE2 support is required. Contrary, I believe that this SSE2 requirement was chosen voluntary, probably from optimization reasons.

I know, I know that's disappointing that Slackware 15.0 32bit does not work fully with your Pentium III worth at its time 1000 dollars (or it was Roman Empire's dinars?) but IF there is a rule regarding the hardware - observed by me in over 12 years of using Slackware, is that it always increased the hardware requirements and it never gone back. Never happened to go back.

So, trying to push your "fixes" in Slackware is probably useless - SSE2 is certainly there to stay and certainly this feature will be required much more in the future.

So, what you will do, when it will not work anymore in your boxes, well... that's your own choice - but looks like Slackware is not designed for your hardware anymore.

1 members found this post helpful.

Apparently there is an alternative rust compiler, written entirely in C++:
https://github.com/thepowersgang/mrustc

FYI: The recent Alpine 3.16 release, is now non-SSE2 compatible, or now being apparently built using "-march=pentium4" per a recent mailing list response and prior bug filing.

As of now, likely no binary distributions supporting any 32-bit archs, or non-SSE2 32-bit CPUs.

Gentoo, or other source based Linux distributions may build to a certain point, however may break at a certain point.

LuckyCyborg: I'd hate to be in your shoes.

In OpenBSD 7.1 for i386 the minimal processor is a Pentium.

In NetBSD 9.2 for i386 the minimal processor is a 486.

Slackware 8.1 will run on a 386. :-)

1 members found this post helpful.