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
Comments
See minimum requirements for Void Linux CPU architectures. If you wanted to have Void for Note, however, that some packages in 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. |
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. |
@dbischof90 Lack of (human) resources is the main reason to not support anything i686 < P4. 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. |
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! |
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.
The text was updated successfully, but these errors were encountered: