Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Various i686 packages do not run on all i686 processors #21486

Closed
dbischof90 opened this issue Apr 30, 2020 · 4 comments
Closed

Various i686 packages do not run on all i686 processors #21486

dbischof90 opened this issue Apr 30, 2020 · 4 comments
Labels
wontfix This will not be worked on

Comments

@dbischof90
Copy link

System

ThinkPad T23, 1GB RAM, Pentium III Tualatine-256 1133MHz (Includes MMX, SSE)

  • xuname:
    Void 5.4.34_1 i686 GenuineIntel uptodate rF

  • package:
    Various packages, explicit examples go and rust

Expected behavior

I would expect that these packages are runnable - at least rust can be compiled for the i586 architecture, so I would expect that the P3 CPU should be able to run it

Actual behavior

After installation and running the programs, I get "Ungültiger Maschinenbefehl", which roughly translate to "Invalid machine instruction" and nothing else happens.

Steps to reproduce the behavior

sudo xbps-install -Syu go; go

I had issues with some packages like Firefox, which now explicitly require SSE2 from the processor, which the P3 doesn't have. However, I am not aware that either rust or go (and various other packages) have that requirement, however it seems to be compiled with an instruction set that is incompatible with the P3. That makes installation via xbps somewhat of trial-and-error process, as programs like python and neovim have no problems and others such as rust and go seem to be problematic without the possibility to know beforehand which one should work.
I posted on reddit as well: https://www.reddit.com/r/voidlinux/comments/gabbgr/i686_packages_should_be_marked_with_their_sse/

I am at this point not fully sure that it is due to SSE/SSE2 but it's my primary suspicion. Can xbps and/or the templates be expanded to differentiate between them and provide the 'correct' binary? After all, the P3 -is- a i686 and I don't think there is a reason go wouldn't run on it. There are programs like Firefox which have explicit bounds on SSE2 for good reasons but I feel that differentiation is a bit unclear for xbps packages.

@pullmoll
Copy link
Member

pullmoll commented Apr 30, 2020

See minimum requirements for Void Linux CPU architectures.

If you wanted to have Void for i[345]86 you'd have to fork void-packages, create new entries for e.g. common/cross-profiles/i586.sh, create a new cross-i586-linux-gnu cross compiler package and then try to cross build a base-chroot for i586with that. If you get this working, you could then try to (cross) build packages you need.

Note, however, that some packages in void-packages are not prepared to build w/o SSE2 support. You'd have to modify them to detect the i586 vs. i686 case.

I'm sure I'm missing quite a few places where additional changes would be required. All in all I wouldn't try to do this but rather get at least a P4.

@pullmoll pullmoll added the wontfix This will not be worked on label Apr 30, 2020
@dbischof90
Copy link
Author

dbischof90 commented Apr 30, 2020

That's true, I should have checked that better. I understand the SSE2 restriction, it's the minimal viable common denominator for some of the current popular packages on x86 32 bit.

I'm just a bit confused as technically almost none of the i686 CPUs are supported if I get that right? (taking a list for example from https://www.linuxquestions.org/questions/linux-hardware-18/what%27s-the-difference-between-i386-i586-and-i686-198431/ ) After all I'm not trying to run on a Pentium I but on one of the later i686. Maybe that can be made more clearer on the webpage.

Is it not viable to include bespoken compiler flag check and provide the SSE2 version in case a compilation with SSE1 is not possible? As mentioned, I see the SSE2 restriction actually only applying for a relative small number of packages (such as FF) and Void could be really a great candidate for old hardware (before one has to fall back to Gentoo for those sweet older laptops). Many of the packages seem to be compiled without SSE2, I can use quite a lot of the packages that xbps provides.

I however also recognize that the number of users that this applies to is most likely limited.

@pullmoll
Copy link
Member

pullmoll commented Apr 30, 2020

@dbischof90 Lack of (human) resources is the main reason to not support anything i686 < P4.
See we are a team of about 20 - 30 active contributors and try to manage a from-scratch Linux distribution with more than 10.000 packages in the repository.

The i686 arch support was already removed completely from all major Linux distributions because it is very legacy and causes trouble to maintain for everyone.

We still have i686 but that's just because some people (including me :) kinda love it to run into problems just to have something to fight against.

@dbischof90
Copy link
Author

That is sad but completely understandable. Actually, i686 support was what drew me to Void, together with having something smaller than systemd for my spare laptop. The poor old thing is somehow still alive so you gotta do something with it :)

But I see that the effort is just not justifiable for the few users that would actually use it. Thanks for your support!

@Chocimier Chocimier mentioned this issue Feb 18, 2021
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants