You are not logged in.
With the build tools emitting SSE2 code like they are currently, anything new that contains binaries strongly risks not working on your nearly 20-year old CPU. Whether this situation is temporary or ongoing still needs to be resolved really, but I'd be looking at alternative distributions if that were my situation still. Debian's 32-bit builds are still i386 as far as I know, and there's Andreas' i486 arch port if that has anything like the packages you actually need. But actually jumping ship today? I wouldn't personally.
I think the package architecture is currently badly named. i686 relates to pentium pro or newer, and SSE2 mainly seems to have come in with the Netburst/P68 microarchitecture which was the Pentium 4 series, although what that's called in linux land I can't guess; i68-86? Whether we rename the arch or stop the build tools spitting out non i686 opcodes remains to be seen, but I'd like one of the two to happen.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
SSE2 actually affects mainly qt5-declarative (where my old patch was failing) and usually the web engines.
MMX, SSE and also SSE2 are emitted by the toolchain, because that's the minimal guarantee Intel gives
for ALL 64-bit CPUs and everything older is considered - well old. I doubt that in the core text-based system
there are SSE2 commands currently (my opcode sniffer could tell, but allas - it's slow and buggy and I didn't
have time to fix it).
The current problem is more due to endbr32 patches in gcc 8.2, which didn't hit stable yet (hence why you
should use testing for - well testing). The problem was, that even when building with i486 emulation in qemu
with --enable-cet and endbr32 in the code, qemu was not emitting a SIGILL (mainly also because this opcode
patching is quite recent) and so I built myself a broken toolchain and mainly a broken glibc 2.28, rendering
the GEODE AMD systems to bricks. I have to build on a VM, because you can't possibly build on a real i486
or even AMD K6 or such.
We could disable CET for modern CPUs too, because I doubt, Intel fixes anything in 32-bit CPUs and thus renders
endbr32 to a series of NOPs.
And yes, I know how to build a toolchain. :-)
And Pentium 3 systems work with endbr32, none of my machines hickuped after the update but the Alix 1.E
with an AMD Geode.
Offline
So, i486 is back and alive. CET disabled. I compiled mpd-light even on a real AMD K6. :-)
If you want to give a try, you need the repos in this order in /etc/pacman.conf:
[staging]
Include = /etc/pacman.d/mirrorlist[testing]
Include = /etc/pacman.d/mirrorlist[core]
Include = /etc/pacman.d/mirrorlist[extra]
Include = /etc/pacman.d/mirrorlist[community-staging]
Include = /etc/pacman.d/mirrorlist[community-testing]
Include = /etc/pacman.d/mirrorlist[community]
Include = /etc/pacman.d/mirrorlist[aba-aur]
Server = http://archlinux32.andreasbaumann.cc/aur/$arch
Then you should be able to install mpd-light.
I'm still not sure, whether there is is enough demand to make this i486 part of Archlinux32..
Offline
I run archlinux32 on an AMD Geode too. Thanks for the work so far.
Offline
I'm still not sure, whether there is is enough demand to make this i486 part of Archlinux32..
You built it, it's there - I think, this is enough to "make it available".
Regards,
deep42thought
Offline
[root@euroalix ~]# mpd -h
mpd: error while loading shared libraries: libicui18n.so.62: cannot open shared object file: No such file or directory
damn, I have to rebuild with icu 62.
Offline
Thank you for this huge amount of work.
I didn't suspect that this"simple" question would rise so many problems…
Perhaps, we are too sentimental (yearning?) in willing to keep our alix-board alive.
Offline
> mpd
Illegal instruction (core dumped)
=> 0x004a2230: f3 0f 1e fb endbr32
*sigh*
again.
Why now?
I was building on an AMD K-6 with march=i486, there is little room for some
stupid auto-detection scripts to enbable CET again..
Offline
So, sorted out. At least 'mpd -h' worked now on the alix. :-)
Offline