I suspect you're going to need rust-bin, but if it's compiled with SSE2, you may be in trouble there too. I'll let someone from Rust figure out if it's avoidable at all, but I doubt it :( Actually, I can't help myself. It looks like it's doable, but without pre-built binaries by upstream (I think), if you build it yourself from an SSE2-capable system first (just for bootstrap): https://fraserblog.codewise.org/rust-on-i586/ if it dev-lang/rust got non sse support I can remove the requirement, sure, but bootstrap problem stays. upstream does not provide i586 installers, which are used by rust-bin. your only way is to follow the article Sam linked and compile own tarball. Then install that tarball onto old system into /opt (like rust-bin does) and Use that rust to bootstrap dev-lang/rust, with system-bootstrap flag enabled. to elaborate a bit, dev-lang/rust uses same installer as rust-bin internally if system-bootstrap is not set. and that one will not work on old CPU. If have another machine to build you could also compile a librsvg/others binpkg directly instead. Much like gcc you can use something like (just an example, adjust as needed): RUSTFLAGS="-Ctarget-cpu=i586 -Ctarget-feature=-sse2" Could also be an occasion to move to building everything on another machine to save that old box some work. Thank you for all the suggestions, the one I like best is Ionen Wolkens's. I will try that first, as I already use distcc & threadripper to build packages for my ancient P166 :-) it may be not that simple with binpkg of librsvg. it uses a weird mix of cargo and autotools. and we have a rust-toolchain.eclass which will always transform i*86 to i686. and librsvg uses that as well. I'll need to remove that assumption, just passing suggested RUSTFLAGS may be not enough. But maybe it'll just work, try it out and let us know. I'll update eclass and ebuild a bit later to allow building for i585 (it will not work out of the box, but at least people could do a bootstrap thing) You're right I need to bootstrap a working i586 rust compiler. I have followed the instructions on that blog article. However, whilst most of the i586 components were there, there doesn't seem to be a i586 component for rustfmt: Submodules updated in 0.02 seconds curl: (22) The requested URL returned error: 404 spurious failure, trying again curl: (22) The requested URL returned error: 404 spurious failure, trying again curl: (22) The requested URL returned error: 404 spurious failure, trying again curl: (22) The requested URL returned error: 404 spurious failure, trying again curl: (22) The requested URL returned error: 404 failed to run: curl -s -y 30 -Y 10 --connect-timeout 30 --retry 3 -Sf -o /tmp/tmpgab6vu9m.sha256 https://static.rust-lang.org/dist/2020-07-12/rustfmt-nightly-i586-unknown-linux-gnu.tar.xz.sha256 Build completed unsuccessfully in 0:00:01 make: *** [Makefile:12: all] Error 1 For what it's worth, I've been manually building rust on my i586 system (an AMD K6-III+) and I would like to transition to using the gentoo package. I initially built rustc by cross-compiling from a newer system, every since then I've been able to build on the system itself. Even if the downloadable bootstrap compiler isn't available, in theory I should be able to do a "system-bootstrap" build from my existing compiler, I'd think? Right now this doesn't work since it forces an i686/sse2 build. I think the fix needed here is that the "sse2" flag shouldn't be forced, but should instead be an option which selects whether to build the "i586" or "i686" version of rustc. I should note that using my manually installed rust compiler, I'm able to successfully install rust packages like librsvg. (I added the rust virtual to package.provided). I suppose this works because I'm on a system with i586 CHOST, so everything matches. I guess you might have problems if you're using an i686 system without SSE2 (P-Pro, P-II, P-III, some Athlon chips) since your CHOST will by i686, but you need to use the i586 version of rust. This Rust mandatory SSE2 CPU instruction requirement is like another plague for those using CPUs' not capable of using the SSE2 CPU instructions set. Enabling SSE2 on non-capable CPU's tends to severely break/segfault binaries, and as I try to recall, with difficult to diagnose error messages. This has been on-going for the past year or so, and started with Mozilla Seamonkey using Rust as a depend, then subsequently also requiring SSE2. (I also think any complaints were merrily ignored... shrugs. It's as if Mozilla developers moved to working/promoting Rust.) Also, some Linux distributions are requiring SSE2, but advertise i686/Pentium3 support, obviously resulting in a broken installation for those having i686/Pentium3 platforms. (eg. Void Linux) In order to save time, I'm focused now on just avoiding rust entirely. Yea, I know, good luck. Once you fix the Rust SSE2 dependency, will then likely have to focus on packages pulling Rust in as a dependency inheriently mandating SSE2 due to the current implied Rust SSE2 dependency. I have several older i686/Pentium3 boxes I use for backup in the event my newer platforms faulter. These older boards are rock stable, albeit laptops/mobile platforms will require locating the hidden CMOS batteries and replacing in order for the laptop/mobile platform to continue being able to boot. Most will likely assume the old laptop is broken, due to the hidden CMOS battery. Think all platforms/CPUS <= i686/pentium3 will be affected by this SSE2 CPUS instruction bug. (In reply to Roger from comment #11) > Think all platforms/CPUS <= i686/pentium3 will be affected by this SSE2 CPUS > instruction bug. Also more modern chips like the entire AMD K7 lineup are i686-compatible CPUs withou SSE2 (early K7 chips lack SSE as well). Anyway rust itself should be compatible with all of these chips, simply by building for i586 target when SSE2 is not available. This is entirely a packaging problem, I think? Doing some brief research via "P6 (microarchitecture) Wikipedia" (eg i686 architecture), I found (and already knew) SSE2 was introduced into the very late variants of the Intel 32bit i686 architecture, specifically during the very later Pentium3's, as I have several mid-to-late era Pentium3's here without SSE2 register, although having the MMX register. The MMX register was subsequently renamed to SSE2 register with some additional minor changes. SSE2 was incorporated into very late era 32bit Intel CPU's, while apparently SSE2 was introduced into AMD 64bit CPU's. NOTE: when compiling code, mmx != sse2 NOTE: sse != sse2 (For those without knowledge of sse/sse2.) NOTE: the MMX register can be utilized as the SSE2 register (SSE2 Wikipedia), with additional trivial coding. To recap, as to why Rust developers neither took the time to incorporate the small MMX capable coding change (although most seem to want to forget MMX all together), or as to why their ignoring these stable platforms and demanding SSE2, guessing completely due to marketing and their budget. Yea, can spend time bootstrapping and creating a separate Ebuild or adding more scripting to the existing rust Ebuild, or just strip rust out of these older platforms, as there are going to be a h*ck lot more packages creating hard dependencies for the Rust language! If this bug is pushed upstream, the bug will just be merrily closed, as reason for my previous stated rational. (I'm already on a seamonkey/rust bug/depency bug mailing list.) Bugs Referencing Rust/SSE2 Dependency "Compiling libcore without SSE leads to LLVM ERROR: SSE register return with SSE disabled #26449" https://github.com/rust-lang/rust/issues/26449 "librsvg2: Contains SSE2 instructions on i686" https://bugzilla.redhat.com/show_bug.cgi?id=1612 If this continues on this path, almost all Linux distributions will need to drop <=i686 as supported platforms rather shortly. This issue should be on the shortlist with political Linux news sites, such as Phoronix, to forewarn, but go figure as to why I'm hearing so little of it. Funny how we inadvertently purrsecute the poor! gnome-base/librsvg-2.48.8.8.ebuild pulls in and hard depends on rust/cargo. Some packages I can now document depending on librsvg: gimp, imagemagick, gegl, ffmpeg, gtk+, adwaita-icon-theme. Not sure if USE="-svg" will work, doubtful. Imagemagick has a use flag for svg, while gimp has a hard depend for svg. Going to have lots of fun uninstalling packages that worked on my Pentium3 platform without SSE2, now hard depending on rust requiring SSE2. Looks like people use depend hooks as a sales tactic... but it's probably just my imagination. (In reply to Roger from comment #14) > gnome-base/librsvg-2.48.8.8.ebuild pulls in and hard depends on rust/cargo. > > Some packages I can now document depending on librsvg: gimp, imagemagick, > gegl, ffmpeg, gtk+, adwaita-icon-theme. > > Not sure if USE="-svg" will work, doubtful. Imagemagick has a use flag for > svg, while gimp has a hard depend for svg. Going to have lots of fun > uninstalling packages that worked on my Pentium3 platform without SSE2, now > hard depending on rust requiring SSE2. > > Looks like people use depend hooks as a sales tactic... but it's probably > just my imagination. Yes, for now, I recommend using the older librsvg. I think it's sad too. No, it's not a sales conspiracy within Gentoo. We just have to put into ebuilds what upstream put in their code. Right, as Georgy Yakovlev in Comment #3 stated, I'm pretty sure the distributed Rust bootstrap is compiled by default with SSE2, for compiling the rust compiler on the target system. I just ran into spidermonkey:78 requiring a hard depend of rust. The spidermonkey:78 version is now (albeit oddly) required for the current x86 Gentoo profile for system required packages: sys-auth/polkit-0.118, sys-auth/elogind-243.7, sys-process/procps-3.3.16-r2. During the past many years, think spidermonkey was only required for elinks commandline browser. Think I now officially have a completely broken x86 laptop here, almost incapable of any updates or stability without rust. (In God we Rust?) The changes with requiring rust likely occurred between ~2020.05.15 and now. (In reply to Roger from comment #17) > I just ran into spidermonkey:78 requiring a hard depend of rust. > > The spidermonkey:78 version is now (albeit oddly) required for the current > x86 Gentoo profile for system required packages: sys-auth/polkit-0.118, > sys-auth/elogind-243.7, sys-process/procps-3.3.16-r2. > I think the output is misleading. It's actually (procps depending on) elogind depending on polkit. There is a draft PR to allow using a lightweight JS engine (Duktape) in Polkit: https://gitlab.freedesktop.org/polkit/polkit/-/merge_requests/35. bug 734326. Think I have a useable system now almost compeltely built, or in the process of finally building world, without rust and without any packages depending on rust. I had to unemerge notification-daemon packages, gtk+, spidermonkey; and subsequently add to package.mask. Set USE="-wxwidgets -policykit -svg -rust" Unemerge any packages depending on the previously mentioned. I've likely corroded down to just using X and dwm, and maybe if I'm lucky, Dillo with no GTK+. As Sam James previously stated sticking with the older svg versions, Gentoo profiling team should mask the newer versions of svg on <64 bit systems, or systems not having the SSE2 CPU register, in order to prevent pulling in or depending on rust bootstrap builds enabling SSE2 optimizations. Stumbled on a good thread for compiling Rust without SSE2, supposedly preserving i586 compatibility. Likely could be performed back to i386, as I'm not seeing any custom code referencing MMX as a substitute, mostly code removals of references leading to SSE2. Perform a search on Google: sse2 rust site:https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/ Page 273, looks like the initial citing of rust SSE2. Page 277, details some remaining lingering SSE2 instructions and firefox. For what it's worth, I manually crosscompiled rustc for i586 a year or so ago, and since then I've been able to do self-hosted builds to keep it updated, and the librsvg ebuild works fine. I'm running on an AMD K6-3, which definitely has no sse! There's only two real problems here: * There's no bootstrap binary rust compiler available for i586 or i686-without-sse2 (although it would be possible to build and provide one), and * The gentoo rust ebuild doesn't select the "i586" target when building with CPU_FLAGS_X86 -sse2, so system-bootstrap can't be used on i586 or i686-without-sse2 machines Slackware Requests for -current (14.2-->15.0) Page 273 https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/page273.html Slackware Requests for -current (14.2-->15.0) Page 277 https://www.linuxquestions.org/questions/slackware-14/requests-for-current-14-2-15-0-a-4175620463/page277.html I am masochistically trying to run gentoo on an Athlon-XP. SSE2 support has been the bane of my existence. The machine is used for retro gaming and I thought it would be neat to get OpenMW running on it (OpenMW is a port of Morrowind which came out around the same time as the hardware I'm running). The only way I'd be able to do it is with Gentoo. games-engines/openmw depends on librsvg and needs a window manager, which means I needed rust. I was able to compile rustc on a separate 32 bit VM, and have that rustc target both i686 and i586. The instructions here are a bit out of date: https://fraserblog.codewise.org/rust-on-i586/ What you really want to do is set your config.toml file like so (of course changing your -march, output directory and potentially other flags) and going through the normal rustc build/install process with x.py. changelog-seen = 2 [llvm] cflags = "-march=\"athlon-4\" -m32" cxxflags = "-march=\"athlon-4\" -m32" ldflags = "-lz" [build] host = ["i586-unknown-linux-gnu", "i686-unknown-linux-gnu"] extended = true configure-args = ['--build=i586-unknown-linux-gnu', '--prefix=/opt'] [install] prefix = "/mnt/disk2/rust/install/opt" If you build rustc like this on another PC, I believe it will work on a non-SSE2 processor. Calvin Walton said: "I suppose this works because I'm on a system with i586 CHOST, so everything matches. I guess you might have problems if you're using an i686 system without SSE2 (P-Pro, P-II, P-III, some Athlon chips) since your CHOST will by i686, but you need to use the i586 version of rust." I did indeed run into this problem trying to build spidermonkey. It forced me to use the i686 rustc target. I also ran into build errors when trying to target i586 for librsvg. So I used an overlay to swap spidermonkey with duktape, and just built librsvg using i686. Ultimately I was not successful in creating a full desktop environment. The xfce4 window manager crashed with illegal instructions. I wonder if librsvg is the culprit. But I was able to launch and run OpenMW eventually. I think Slackware also may have mitigated the SSE2 requirements as well, from my last reading of their lengthy log file on the next slackware-15.0 next release. God, there has to be Linux distributions capable of using the ~15 year old technology! The real reason for Rust requiring SSE2, Rust developers have officially commented they see no use for non-SSE2 capable CPU's, and have such, stopped maintaining their optimizing code for working without SSE2 CPU optimization within Rust. (There's an open bug for Rust SSE2, but the open bug report is not for users... ) On that note, I have no need for Rust language, or code requiring users to always buy newer hardware. As such, I avoid Rust related projects as much as possible. You'll likely notice some not caring, and just buying newer hardware on whim... I've slowly, after more than 15 years, purchased a newer (and the most affordable) Dell Inspiron laptop with Intel Xe GPU, completely avoiding proprietary GPU's. I still have lots of working Intel Pentium non SSE2 hardware, gathering dust only due to lack of floor space, otherwise I would have them working with at least Gentoo or Slackware. This is dreadful. I am trying to rebuild a functional modern distro for the OLPC XO-1. I tried to run Debian 11 and I had the same problem. This is an AMD Geode (CPU Family 5, Model 10, Stepping 2). It has the contemporary 3dnowext instruction set, but I doubt rust has optimizations for that. I found online where they were rationalizing requiring SSE2 and they were using the Valve Steam hardware survey as justification, as if that encompasses the entire Linux user-base. https://groups.google.com/g/mozilla.dev.platform/c/V1h-paV7deM?pli=1 Taking a stab at Gentoo (I have years of experience with it) and I am having the same problem. Adding -gtk -gtk2 to use flags, and I am off and building, but this limits the functionality of this system. There are still millions of OLPC XO's being used around the world, so this is certainly still an extant platform. I don't know if my application justifies Gentoo patching rust to work on this hardware. The community won't be enthusiastic about using something other than Fedora or Debian. It's just upsetting that a single package can render a decade old piece of hardware, with a million strong user-base, obsolete. (In reply to Corey McGuire from comment #26) > This is dreadful. I am trying to rebuild a functional modern distro for the > OLPC XO-1. I tried to run Debian 11 and I had the same problem. > > This is an AMD Geode (CPU Family 5, Model 10, Stepping 2). It has the > contemporary 3dnowext instruction set, but I doubt rust has optimizations > for that. > > I found online where they were rationalizing requiring SSE2 and they were > using the Valve Steam hardware survey as justification, as if that > encompasses the entire Linux user-base. > > https://groups.google.com/g/mozilla.dev.platform/c/V1h-paV7deM?pli=1 > > Taking a stab at Gentoo (I have years of experience with it) and I am having > the same problem. Adding -gtk -gtk2 to use flags, and I am off and building, > but this limits the functionality of this system. > > There are still millions of OLPC XO's being used around the world, so this > is certainly still an extant platform. > > I don't know if my application justifies Gentoo patching rust to work on > this hardware. The community won't be enthusiastic about using something > other than Fedora or Debian. > > It's just upsetting that a single package can render a decade old piece of > hardware, with a million strong user-base, obsolete. You can mask the newer packages that need ugly rust in package.mask (snippet from my AMD K6-III): # rust dosnt work on this arch dev-lang/rust dev-lang/rust-bin virtual/rust # this gnome shit needs now rust too, gross! >=gnome-base/librsvg-2.48 After that, it will build 2.40.21 which is without rust and still works. Keep a copy of the ebuild and the distfile librsvg-2.40.21.tar.xz for later building, in case it goes out of the portage tree. BR Xeha Xeha,
For the past few months, I have been working on doing an i486 compile of Gentoo Linux.
Thanks for suggesting the existence of librsvg 2.40.21.
It turns out librsvg 2.40.21 is still available through the Gentoo repository for x86 (not x86-64).
One needs to install x11-themes/adwaita-icon-theme 3.32.0 along with the older librsvg to be able to install light weight desktop environment like LXDE.
# emerge -av =x11-themes/adwaita-icon-theme-3.32*
Based on your suggestion of package masking rust and librsvg 2.41 and over, I was able to successfully do an i486 compile of LXDE.
However, here is where I stumbled.
It turns out genkernel supplies i686 (Pentium Pro) configured Linux kernel configuration file for compiling Linux kernel.
Specifically, it enables CMOV instructions that became available starting with Pentium Pro.
In order to compile for i486 and various Pentium class processors, one needs to make sure CMOV instructions are not generated by gcc.
I edited .config Linux kernel configuration file to specifically target i486SX (i486 without an FPU).
I filed Gentoo Bug 812350 regarding this issue.
Anyone trying to get the latest Gentoo Linux to run on Pentium class processors like AMD-K6 need to change the default .config installed by genkernel when letting genkernel build the Linux kernel.
# genkernel all
This also applies to the original configuration file located at /usr/share/genkernel/arch/x86/generated-config.
If anyone is confused with my explanation, always check the CPU target architecture of the Linux kernel before building it.
Otherwise, one can run into problems like I faced.
(In reply to Xeha from comment #27)
> (In reply to Corey McGuire from comment #26)
> > This is dreadful. I am trying to rebuild a functional modern distro for the
> > OLPC XO-1. I tried to run Debian 11 and I had the same problem.
> >
> > This is an AMD Geode (CPU Family 5, Model 10, Stepping 2). It has the
> > contemporary 3dnowext instruction set, but I doubt rust has optimizations
> > for that.
> >
> > I found online where they were rationalizing requiring SSE2 and they were
> > using the Valve Steam hardware survey as justification, as if that
> > encompasses the entire Linux user-base.
> >
> > https://groups.google.com/g/mozilla.dev.platform/c/V1h-paV7deM?pli=1
> >
> > Taking a stab at Gentoo (I have years of experience with it) and I am having
> > the same problem. Adding -gtk -gtk2 to use flags, and I am off and building,
> > but this limits the functionality of this system.
> >
> > There are still millions of OLPC XO's being used around the world, so this
> > is certainly still an extant platform.
> >
> > I don't know if my application justifies Gentoo patching rust to work on
> > this hardware. The community won't be enthusiastic about using something
> > other than Fedora or Debian.
> >
> > It's just upsetting that a single package can render a decade old piece of
> > hardware, with a million strong user-base, obsolete.
>
>
> You can mask the newer packages that need ugly rust in package.mask (snippet
> from my AMD K6-III):
> # rust dosnt work on this arch
> dev-lang/rust
> dev-lang/rust-bin
> virtual/rust
>
> # this gnome shit needs now rust too, gross!
> >=gnome-base/librsvg-2.48
>
>
> After that, it will build 2.40.21 which is without rust and still works.
> Keep a copy of the ebuild and the distfile librsvg-2.40.21.tar.xz for later
> building, in case it goes out of the portage tree.
>
> BR
> Xeha
Created attachment 757012 [details]
Internal configuration file for dev-lang/rust-1.56.1 source
Must say this bugtracker is a very clever tool - deletes entire message after uploading the attachment... :( I really wish not to type it again. I just mention, I've tried what Dylan Rush suggested (#24) and no go... Tried different cflags (attached file), while compiling (not cross-compiling) the thing. The rust-1.56.1 source, internal x.py emerges some 1.55*i686-unknown-linux-gnu tarballs, extracts them, later builds(?) some stuff but in result, it ends up with a tool called 'carrgo' (extracted / not source-compiled) that it tries to execute (with illegal instruction error, of course). (I have Pentium 3 S-series 1400MHz)... I came up here (and few other threads and forum posts after when trying to update the LXDE desktop and www-client/seamonkey-2.49 (bin) (aiming for 2.53 source). You'll likely find the illegal instruction issued to the CPU was an SSE2 instruction, for which rust depends on. You'll find the error, by either examining far back before the break in compile, or finding the broken compiler statement, manually issuing the compiler statement; and may finally find the CPU SSE2 call. It's a tough one to find, but with a little tedious footwork, can be found. The same SSE2 dependency also occurs with seamonkey/seamonkey-bin after a certain seamonkey version. If you do some research on Google, you'll likely find a website listing packages and packages support for non-SSE2 cpu's, for which also lists the last known version of seamonkey without the required CPU SSE2 usage. It maybe, the next version of Slackware may still provide support for non-SSE2 cpu's. I know there was quite a bit of talk on the slackware next release forum/thread about compiling rust without SSE2 optimizations. Just have to be cautious, there were a few Pentium 3 CPU's with SSE2, released during the last days of the Pentium 3 manufacturing. As such, some distribution's still erroneously sometimes cite P3 support, when the distribution does not support non-SSE2 capable CPU's. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bff66eedb4ae530ef21187d617daeba5472320a1 commit bff66eedb4ae530ef21187d617daeba5472320a1 Author: Georgy Yakovlev <gyakovlev@gentoo.org> AuthorDate: 2022-01-20 04:32:00 +0000 Commit: Georgy Yakovlev <gyakovlev@gentoo.org> CommitDate: 2022-01-20 04:36:38 +0000 dev-lang/rust: pass -fcf-protection=none on i586 while building for i586 targets we need to explicitly opt out of cet in internal llvm build. we don't even support bootstrapping this target right now as there is no self-hosting version, but may support in the future via our own tarball. Bug: https://bugs.gentoo.org/741708 Issue: https://github.com/rust-lang/rust/issues/93059 Signed-off-by: Georgy Yakovlev <gyakovlev@gentoo.org> dev-lang/rust/rust-1.58.0.ebuild | 8 ++++++++ 1 file changed, 8 insertions(+) *** Bug 851909 has been marked as a duplicate of this bug. *** This isn't a proper solution yet, but FWIW: - I wrote https://wiki.gentoo.org/wiki/User:Sam/Drafts/Bootstrapping_Rust_cross for bootstrapping from another arch (amd64->sparc) - immolo is working on https://wiki.gentoo.org/wiki/User:Immolo/rust_i686 (it's not finished yet) which is an adaptation of mine but for this situation This can be worked around now using https://wiki.gentoo.org/wiki/Rust_x86_without_SSE2 this only works on glibc systems at the moment but I'll solve the Musl issues hopefully when time allows. Ouch, my C3 Eden computer do not have sse2 ... I'm impacted with a new dependence with rust !
c3eden ~ # emerge -auDNv @world
These are the packages that would be merged, in order:
Calculating dependencies... done!
!!! The ebuild selected to satisfy "~dev-lang/rust-1.65.0[rustfmt?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]" has unmet requirements.
- dev-lang/rust-1.65.0::gentoo USE="-clippy -debug -dist -doc (-llvm-libunwind) (-miri) (-nightly) (-parallel-compiler) (-profiler) -rust-analyzer -rust-src -rustfmt (-system-bootstrap) (-system-llvm) -test -verify-sig -wasm" CPU_FLAGS_X86="-sse2" LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARM -AVR -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore"
The following REQUIRED_USE flag constraints are unsatisfied:
x86? ( cpu_flags_x86_sse2 )
The above constraints are a subset of the following complete expression:
any-of ( llvm_targets_AArch64 llvm_targets_AMDGPU llvm_targets_ARM llvm_targets_AVR llvm_targets_BPF llvm_targets_Hexagon llvm_targets_Lanai llvm_targets_Mips llvm_targets_MSP430 llvm_targets_NVPTX llvm_targets_PowerPC llvm_targets_RISCV llvm_targets_Sparc llvm_targets_SystemZ llvm_targets_WebAssembly llvm_targets_X86 llvm_targets_XCore ) miri? ( nightly ) parallel-compiler? ( nightly ) rust-analyzer? ( !wasm ) test? ( llvm_targets_AArch64 llvm_targets_AMDGPU llvm_targets_ARM llvm_targets_AVR llvm_targets_BPF llvm_targets_Hexagon llvm_targets_Lanai llvm_targets_Mips llvm_targets_MSP430 llvm_targets_NVPTX llvm_targets_PowerPC llvm_targets_RISCV llvm_targets_Sparc llvm_targets_SystemZ llvm_targets_WebAssembly llvm_targets_X86 llvm_targets_XCore ) wasm? ( llvm_targets_WebAssembly ) x86? ( cpu_flags_x86_sse2 )
(dependency required by "virtual/rust-1.65.0-r1::gentoo" [ebuild])
(dependency required by "gnome-base/librsvg-2.55.1::gentoo" [ebuild])
(dependency required by "x11-libs/gtk+-3.24.35::gentoo" [ebuild])
(dependency required by "x11-themes/adwaita-icon-theme-43_p1::gentoo" [ebuild])
(dependency required by "virtual/freedesktop-icon-theme-0-r4::gentoo" [ebuild])
(dependency required by "net-analyzer/wireshark-4.0.3::gentoo" [ebuild])
(dependency required by "@selected" [set])
(dependency required by "@world" [argument])
i filed MCPs with Rust 6 months ago to either promote the i586-linux-gnu target to Tier 2 with host tools, or to fix their i686 definition. the MCP for the former action has been seconded, which means that there will be official binaries for Rust on i586 soon, which will enable workarounds for this without having to do cross-compilation from another machine. my dual Pentium 3 machine and i are very happy about this. (In reply to linear cannon from comment #37) > i filed MCPs with Rust 6 months ago to either promote the i586-linux-gnu > target to Tier 2 with host tools, or to fix their i686 definition. the MCP > for the former action has been seconded, which means that there will be > official binaries for Rust on i586 soon, which will enable workarounds for > this without having to do cross-compilation from another machine. my dual > Pentium 3 machine and i are very happy about this. Wunderbar! I can't wait to get my i586 VM rebuilt! Created attachment 853870 [details]
make.conf file of the SSE2 crossbuild machine
Created attachment 853872 [details]
cpu-flags of the SSE2 crossbuild machine
Created attachment 853874 [details]
make.conf of the SSE2 crossbuild machine
Created attachment 853876 [details]
make.conf of the non-SSE2 target machine
Created attachment 853878 [details]
cpu-flags of the non-SSE2 target machine
Created attachment 853880 [details]
edited rust-1.65.0 ebuild of the non-SSE2 target machine
Created attachment 853882 [details]
abbreviated build log of the non-SSE2 target machine
Created attachment 853884 [details]
environment file of the non-SSE2 target machine
Created attachment 853886 [details]
emerge --info '=dev-lang/rust-1.65.0::x-tmp' output of the non-SSE2 target machine
(In reply to immolo from comment #35) > This can be worked around now using... Immolo, First thank you for the work on the wiki page. Sorry that I had to shorten your comment I'm replying to but I've lost my first reply because of the link in it (new account here), so... I've tried following your instructions on crossbuilding an i586 targeted rust on an SSE2 machine and then using that to bootstrap rust without SSE2 on my non-SSE2 machine; however, I've encountered the same error every time. Tried multiple times, first I had a crossbuild VM based on x86 Linux Mint 19.3 with a clean Gentoo i686 stage-3 chroot, then after the error came despite recompiling for i586 target multiple times and trying to bootstrap, I've done a full install of Gentoo i686 in a VM (libc, OpenRC), and tried that way. It's always the same error, which occurs on the target machine in the first bootstrapping phase. I'd really appreciate you taking a look at this if you have the time. I want to resurrect this machine for sentimental reasons with a modern OS with GUI but if I try to install a desktop environment and GUI apps, or just select the desktop eselect target, sooner or later something hard depends on rust, so I can't proceed further without bootstrapping rust on it... The crossbuild machine: - Intel Core i7 mobile CPU (Haswell), 12 GB RAM -- 4 vCPU and 4 GB RAM granted to Gentoo VM - On a Hyper-V VM: minimal Gentoo i686 install (libc, OpenRC) + sys-devel/clang, dev-vcs/git, dev-util/cmake, eselect-rust The target machine: - AMD Athlon XP CPU, 1 GB RAM - Minimal (clean) Gentoo i686 install (libc, OpenRC) with manually built kernel (version: 5.15.88) - Has MMX, MMXExt, 3dNow!, 3dNow!ext, SSE but no SSE2 I followed your instructions on the wiki page almost to the letter, aside from using 'git checkout 1.65.0' instead of 'git checkout 1.64.0' since the protage tree has ebuilds only for >=1.65.0 and the wiki also references 1.65.0 everywhere else. The error is in the attached abbreviated build.log (the original is too large to attach, but this has everything from the start of the building of the part that causes the problem. I've also attached the make.conf and the 00cpu-flags file of the crossbuild machine, the make.conf and 00cpu-flags file of the target machine, the edited rust-1.65.0.ebuild file, the environment file and the output of "emerge --info '=dev-lang/rust-1.65.0::x-tmp'". I couldn't attach the output of "emerge -pqv '=dev-lang/rust-1.65.0::x-tmp'" since that one quits with the following error: emerge: there are no ebuilds to satisfy "=dev-lang/rust-1.65.0::x-tmp". Thank you in advance for any help or advice! I can try out whatever modifications you'd suggest on the procedure but it will take some time since the error occurs on the target machine after about 14 hours of compilation, plus if I have to do a new crossbuild it takes 5 and a half hours. Can you pop on to irc.gentoo.org #gentoo-rust and ask your question there then I can either help better once I'm back from work. Thanks to linear cannon's great efforts, i586-unknown-linux-gnu is now available with host tools (see https://doc.rust-lang.org/nightly/rustc/platform-support.html). We just need to figure out how to wire that up now. (In reply to Sam James from comment #50) > Thanks to linear cannon's great efforts, i586-unknown-linux-gnu is now > available with host tools (see > https://doc.rust-lang.org/nightly/rustc/platform-support.html). > > We just need to figure out how to wire that up now. ... did I completely misunderstand it, actually? There were a few proposals: 1) https://github.com/rust-lang/compiler-team/issues/543 (accepted) (implementation: https://github.com/rust-lang/rust/pull/108716). 2) https://github.com/rust-lang/compiler-team/issues/548 (rejected in favour of 543) (implementation: https://github.com/rust-lang/rust/pull/100969) 1) was accepted as an idea, but its implementation PR got closed. Going off https://doc.rust-lang.org/nightly/rustc/platform-support.html, I don't see the host tools available. Therefore there's nothing for us to do on our end yet, other than possibly build our own bins? *** Bug 927047 has been marked as a duplicate of this bug. *** I've just got hit by this on dual socket Pentium 3 1400MHz.
The dependency came up in @preserved-rebuild after a full system upgrade:
!!! The ebuild selected to satisfy "~dev-lang/rust-bin-1.74.1[rustfmt?,abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]" has unmet requirements.
- dev-lang/rust-bin-1.74.1::gentoo USE="(-big-endian) -clippy -doc (-prefix) -rust-analyzer -rust-src -rustfmt -verify-sig" CPU_FLAGS_X86="-sse2"
The following REQUIRED_USE flag constraints are unsatisfied:
x86? ( cpu_flags_x86_sse2 )
(dependency required by "virtual/rust-1.74.1::gentoo" [ebuild])
(dependency required by "dev-python/setuptools-rust-1.8.1::gentoo" [ebuild])
(dependency required by "dev-python/cryptography-41.0.7::gentoo" [ebuild])
(dependency required by "@preserved-rebuild" [argument])
Then I tried to install dev-lang/rust-bin with SSE2 while mounting this system on a chroot, on a system that can do SSE2, so that then I can compile dev-lang/rust without SSE2. Turns out not even this can be done:
!!! The ebuild selected to satisfy "dev-lang/rust" has unmet requirements.
- dev-lang/rust-1.74.1::gentoo USE="(-big-endian) -clippy -debug -dist -doc -llvm-libunwind (-lto) -miri -nightly -parallel-compiler -profiler -rust-analyzer -rust-src -rustfmt -system-bootstrap -system-llvm -test -verify-sig -wasm" CPU_FLAGS_X86="-sse2" LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARC -ARM -AVR -BPF -CSKY -DirectX -Hexagon -Lanai -LoongArch -M68k -MSP430 -Mips -NVPTX -PowerPC -RISCV -SPIRV -Sparc -SystemZ -VE -WebAssembly -XCore -Xtensa"
The following REQUIRED_USE flag constraints are unsatisfied:
x86? ( cpu_flags_x86_sse2 )
To add salt to injury, the offending package dev-python/cryptography doesn't even have the version that doesn't require rust anymore:
# ls /var/db/repos/gentoo/dev-python/cryptography/ -l
total 72
-rw-r--r-- 1 root root 37498 Mar 2 18:10 Manifest
-rw-r--r-- 1 root root 3438 Nov 29 16:10 cryptography-41.0.7.ebuild
-rw-r--r-- 1 root root 3331 Jan 23 06:41 cryptography-42.0.0.ebuild
-rw-r--r-- 1 root root 3331 Jan 25 06:41 cryptography-42.0.1.ebuild
-rw-r--r-- 1 root root 3331 Jan 31 08:11 cryptography-42.0.2.ebuild
-rw-r--r-- 1 root root 3331 Feb 16 07:11 cryptography-42.0.3.ebuild
-rw-r--r-- 1 root root 3329 Feb 22 02:10 cryptography-42.0.4.ebuild
-rw-r--r-- 1 root root 3352 Mar 2 18:10 cryptography-42.0.5.ebuild
-rw-r--r-- 1 root root 464 Oct 28 2022 metadata.xml
Rust is an awful zoomer nulang and I hate it. Just imagine that rust devs invented an entire language that deprecates swaths of hardware just so they don't have to stop watching tiktok to learn how to run valgrind and gdb.
(In reply to Michał Dec from comment #53) > I've just got hit by this on dual socket Pentium 3 1400MHz. > > The following REQUIRED_USE flag constraints are unsatisfied: > x86? ( cpu_flags_x86_sse2 ) > Hi Michał. I successfully built rust for Duron today. I had Rust 1.66.1 already compiled and installed according the convoluted steps above. Then I just removed SSE2 checks from the latest rust ebuild file k6 ~ # diff -u /var/db/repos/gentoo/dev-lang/rust/rust-1.77.1.ebuild.orig /var/db/repos/gentoo/dev-lang/rust/rust-1.77.1.ebuild --- /var/db/repos/gentoo/dev-lang/rust/rust-1.77.1.ebuild.orig 2024-04-12 17:27:49.817707929 +0200 +++ /var/db/repos/gentoo/dev-lang/rust/rust-1.77.1.ebuild 2024-04-12 14:42:34.327698065 +0200 @@ -42,7 +42,7 @@ LICENSE="|| ( MIT Apache-2.0 ) BSD BSD-1 BSD-2 BSD-4" -IUSE="big-endian clippy cpu_flags_x86_sse2 debug dist doc llvm-libunwind lto miri nightly parallel-compiler profiler rustfmt rust-analyzer rust-src system-bootstrap system-llvm test wasm ${ALL_LLVM_TARGETS[*]}" +IUSE="big-endian clippy debug dist doc llvm-libunwind lto miri nightly parallel-compiler profiler rustfmt rust-analyzer rust-src system-bootstrap system-llvm test wasm ${ALL_LLVM_TARGETS[*]}" # Please keep the LLVM dependency block separate. Since LLVM is slotted, # we need to *really* make sure we're not pulling more than one slot @@ -128,7 +128,6 @@ rust-analyzer? ( rust-src ) test? ( ${ALL_LLVM_TARGETS[*]} ) wasm? ( llvm_targets_WebAssembly ) - x86? ( cpu_flags_x86_sse2 ) " # we don't use cmake.eclass, but can get a warning Recompute the package manifest k6 ~ # ebuild /var/db/repos/gentoo/dev-lang/rust/rust-1.77.1.ebuild manifest Mask updates of rust so I dont have to bother with its updates for some time k6 ~ # cat /etc/portage/package.mask/rust >=virtual/rust-1.77.1 >=dev-lang/rust-1.77.1 dev-lang/rust-bin Accept ~x86 for rust k6 ~ # cat /etc/portage/package.accept_keywords/rust dev-lang/rust ~x86 virtual/rust ~x86 Use flag system-bootstrap disabled. That should be the default though. And then emerge. I am not sure whether having nonSSE2 rust already installed is a requirement. Please try it out and report back. k6 ~ # grep COMMON_FLAGS\= /etc/portage/make.conf COMMON_FLAGS="-Os -fomit-frame-pointer -march=athlon-4 --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=64 -mtune=athlon -pipe -mno-3dnow -mno-3dnowa" k6 ~ # rustc -Vv rustc 1.77.1 (7cf61ebde 2024-03-27) (gentoo) binary: rustc commit-hash: 7cf61ebde7b22796c69757901dd346d0fe70bd97 commit-date: 2024-03-27 host: i686-unknown-linux-gnu release: 1.77.1 LLVM version: 17.0.6 Actually I spoke too soon. It only compiles successfully (in my qemu build VM). The resulting binary still contains SSE2 instructions. I only realized that after installing it on real hardware. I got rust working now even on real PC with old Duron. I had to add RUSTFLAGS to make.conf. Which makes sense but I did not know about this variable until today. add to /etc/portage/make.conf RUSTFLAGS="-C target-cpu=i686" and then rebuild again. So simply remove SSE2 checks from ebuild, make sure you have correct RUSTGLAGS and that should be it. This patch is from Debian and lowers the baseline from Pentium4 to pentiumpro which has been the source of our problem. I've tested this in multiple QEMU VMs with SSE2 disabled and checked with iced-cpuid to find no sse2 has leaked into any program I've tested so far. If some of the users here could test this please and report back their finding it would be a huge help as currently I do not have access to my x86 hardware. It cannot be compiled right away. I need to get previous version of rust. I will test it eventually once I work this around.
!!! The ebuild selected to satisfy "=dev-lang/rust-bin-1.80*" has unmet requirements.
- dev-lang/rust-bin-1.80.1::gentoo USE="(-big-endian) -clippy -doc (-prefix) -profiler -rust-analyzer -rust-src -rustfmt -verify-sig" CPU_FLAGS_X86="-sse2"
The following REQUIRED_USE flag constraints are unsatisfied:
x86? ( cpu_flags_x86_sse2 )
(dependency required by "dev-lang/rust-1.81.0::gentoo[system-bootstrap]" [ebuild])
(dependency required by "=dev-lang/rust-1.81.0" [argument])
However I have a question about the patch. Why is PentiumPro chosen as a baseline? Wouldnt then rust fail on 486, Pentium, PentiumMMX, K5, K6 and so on?
Please unset the system-bootstrap USE flag. As for the baseline it's the first i686 cpu and the ebuild is wired up for it so made sense to get one of the three working for now. > Why is PentiumPro chosen as a baseline? I am not the author of the patch, but I would start with looking at the opcodes introduced in the Pentium and Pentium Pro that do not exist in 486. Our starting point is here: https://en.wikipedia.org/wiki/X86_instruction_listings#Added_in_P5/P6-class_processors The P5/P6 section lists a lot of things added in prior 386 and 486 processors that are not necessarily from Intel (386 and 486 implementations from IBM and Cyrix) or were added in later revisions of Intel's 386 and 486 offerings (386SL, 486SL) RDMSR - added in Pentium (ring 0) RSM - added in Pentium, Intel 386SL and Intel 486SL, therefore I'm not enitrely sure that rustc and gcc would emit those instructions on -march=486 or -march=386 (ring -2) CPUID - added in Pentium CMPXCHG8B - added in Pentium RDTSC - added in Pentium (needed for 64 bit time on 32 bit arch) UD1 - added in Pentium (purposefuly triggers undefined opcode error for testing purposes) UD2B - added in Pentium (purposefuly triggers undefined opcode error for testing purposes) Now, here's the stuff that sets apart the mmx and pro varieties from baseline Pentium: RDPMC - added in MMX and Pro (concerns hardware performance counters) CMOVcc - added in Pro (conditional move to register) NOPL - added in Pro (long no-op) So from what I see, there's a handful of useful opcodes in Pentium Pro. Maybe the bar can be lowered? But personally I don't think going below the basic Pentium is worth it due to 64 bit time support, considering that 32 bit epoch is about to finish and overflow. Tested on Duron "Morgan" (Model 7, 180 nm) 1200MHz. It has MMX, SSE but not SSE2. -compiled Rust binpkg in VM -installed Rust binpkg in real HW -compiled rust reimplementation of coreutils https://github.com/uutils/coreutils on real HW. -no error spotted I also have AMD K6-2 which I am planning to test on also, but it will take some day or two. Regarding the patch, I really think the baseline should be 486. Gentoo provides stage3 for i486 so it is reasonable to assume 486 and newer are supported in all packages (if possible). Also the Gentoo handbook https://wiki.gentoo.org/wiki/Handbook:X86/Installation/Media states i486 as a minimum CPU. These CPUs are so slow its users are used to wait and know what to expect. Enabling some extra instructions introduced in PentiumPro will not make huge difference in speed I bet. I personally need Rust only to satisfy the other package dependencies. And maybe one day it will be required to even install the kernel itself. > I personally need Rust only to satisfy the other package dependencies Don't we all? I never woke up one day and been like "mmm yes, I need rust for le reasons". I need it because someone else decided this and there's no way out. But rest assured rust users will try defend it tooth and nail that "nObOdY iS fOrCiNg yOu To UsE rUsT". The same way nobody is forcing you to use electricity. I reported https://bugs.gentoo.org/927047 because I eventually hit https://github.com/pyca/cryptography/issues/5771 Can we please keep this to the technical side of Rust, we are closing in on solving this issue now. Hi, So I tested it on AMD K6-II and Rust failed with this patch. The illegal instruction is nopw. -compiled Rust binpkg in VM - OK -installed Rust binpkg on real HW - OK -run rustc on real HW - FAIL! k6 ~ # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 5 model : 8 model name : AMD-K6(tm) 3D processor stepping : 12 cpu MHz : 451.028 cache size : 64 KB fdiv_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr cx8 pge mmx syscall 3dnow k6_mtrr cpuid 3dnowprefetch vmmcall bugs : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass bogomips : 902.05 clflush size : 32 cache_alignment : 32 address sizes : 32 bits physical, 32 bits virtual k6 ~ # gdb --args rustc -V GNU gdb (Gentoo 14.2 vanilla) 14.2 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from rustc... (No debugging symbols found in rustc) (gdb) run Starting program: /usr/bin/rustc -V [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. 0xaf338cca in std::rt::lang_start_internal () from /usr/lib/rust/lib/libstd-860e1f3ab53f533b.so (gdb) (gdb) display/i $pc 1: x/i $pc => 0xaf338cca <_ZN3std2rt19lang_start_internal17hfa6237e9179245e0E+90>: nopw 0x0(%eax,%eax,1) (gdb) Can you please dump the opcode for nopw? There's at 3 ways to write it: https://stackoverflow.com/a/12564044 (In reply to Michał Dec from comment #65) > Can you please dump the opcode for nopw? There's at 3 ways to write it: > https://stackoverflow.com/a/12564044 Sure. It is: 66 0f 1f 44 00 00 nopw 0x0(%eax,%eax,1) (In reply to vanilkovy.puding from comment #64) > Hi, > So I tested it on AMD K6-II and Rust failed with this patch. > The illegal instruction is nopw. Thanks for testing! I can't find much on this instruction other than some vague references to it being related to Intel CPUs. I've pushed a new patch which lowers to i486 so could you try this next please? Hi immolo, With i486 I get error message during the compilation (towards the end of it). Seems similar to this bug report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267622 error: linking with `i486-pc-linux-gnu-gcc` failed: exit status: 1 | = note: LC_ALL="C" PATH="/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/bin:/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/bin:/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/bin:/var/tmp/portage/dev-lang/rust-1.81.0/temp/python3.12/bin:/usr/lib/portage/python3.12/ebuild-helpers/xattr:/usr/lib/portage/python3.12/ebuild-helpers:/usr/local/sbin:/usr/local/bin:/usr/bin:/opt/bin:/usr/lib/llvm/18/bin:/usr/lib/llvm/17/bin:/usr/lib/llvm/16/bin" VSLANG="1033" "i486-pc-linux-gnu-gcc" "-m32" "/var/tmp/portage/dev-lang/rust-1.81.0/temp/rustcVQpxen/symbols.o" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1-rustc/release/build/memchr-795bbac5efd0164d/build_script_build-795bbac5efd0164d.build_script_build.8a39a00025f0891-cgu.0.rcgu.o" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1-rustc/release/build/memchr-795bbac5efd0164d/build_script_build-795bbac5efd0164d.2cb7jfuogtmml37gpwipx7etr.rcgu.o" "-Wl,--as-needed" "-L" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1-rustc/release/deps" "-L" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libstd-860e1f3ab53f533b.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libpanic_unwind-36d7d9c7b4d830f9.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libobject-784bebb62d25bb4d.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libmemchr-96f68a1c1d409b04.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libaddr2line-77fcc6ed67c538f1.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libgimli-a667b3ca7fc5210e.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/librustc_demangle-217625560d986372.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libstd_detect-20f3fc6034c33bac.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libhashbrown-8f514d01c7ddfe07.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/librustc_std_workspace_alloc-08ca2ed3e140a4a6.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libminiz_oxide-3a74acb32eb2cd44.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libadler-8594fbe28bc5696a.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libunwind-5e6f4acdbad5d62c.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libcfg_if-b80b7aaa966944af.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/liblibc-aa713a96afd88f1f.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/liballoc-94b0f77f4f09dce0.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/librustc_std_workspace_core-b5d4d5502ef68272.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libcore-b4cc9a4ec77952ef.rlib" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libcompiler_builtins-0660814f978e50e0.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib" "-o" "/var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1-rustc/release/build/memchr-795bbac5efd0164d/build_script_build-795bbac5efd0164d" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" = note: /usr/lib/gcc/i486-pc-linux-gnu/13/../../../../i486-pc-linux-gnu/bin/ld: /var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libstd-860e1f3ab53f533b.rlib(std-860e1f3ab53f533b.std.bb3cc3eba9418e46-cgu.0.rcgu.o): in function `core::ptr::drop_in_place<std::sync::reentrant_lock::ReentrantLockGuard<core::cell::RefCell<std::io::buffered::linewriter::LineWriter<std::io::stdio::StdoutRaw>>>>': std.bb3cc3eba9418e46-cgu.0:(.text._ZN4core3ptr175drop_in_place$LT$std..sync..reentrant_lock..ReentrantLockGuard$LT$core..cell..RefCell$LT$std..io..buffered..linewriter..LineWriter$LT$std..io..stdio..StdoutRaw$GT$$GT$$GT$$GT$17h7509f42dbf02615dE+0x24): undefined reference to `__atomic_store_8' /usr/lib/gcc/i486-pc-linux-gnu/13/../../../../i486-pc-linux-gnu/bin/ld: /var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libstd-860e1f3ab53f533b.rlib(std-860e1f3ab53f533b.std.bb3cc3eba9418e46-cgu.0.rcgu.o): in function `std::thread::Thread::new_inner': std.bb3cc3eba9418e46-cgu.0:(.text._ZN3std6thread6Thread9new_inner17h862f04374602721aE+0x85): undefined reference to `__atomic_load_8' /usr/lib/gcc/i486-pc-linux-gnu/13/../../../../i486-pc-linux-gnu/bin/ld: std.bb3cc3eba9418e46-cgu.0:(.text._ZN3std6thread6Thread9new_inner17h862f04374602721aE+0xba): undefined reference to `__atomic_compare_exchange_8' /usr/lib/gcc/i486-pc-linux-gnu/13/../../../../i486-pc-linux-gnu/bin/ld: /var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libstd-860e1f3ab53f533b.rlib(std-860e1f3ab53f533b.std.bb3cc3eba9418e46-cgu.0.rcgu.o): in function `<&std::io::stdio::Stdout as std::io::Write>::write_fmt': std.bb3cc3eba9418e46-cgu.0:(.text._ZN61_$LT$$RF$std..io..stdio..Stdout$u20$as$u20$std..io..Write$GT$9write_fmt17h5fa8453443ac29d9E+0xd4): undefined reference to `__atomic_store_8' /usr/lib/gcc/i486-pc-linux-gnu/13/../../../../i486-pc-linux-gnu/bin/ld: /var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libstd-860e1f3ab53f533b.rlib(std-860e1f3ab53f533b.std.bb3cc3eba9418e46-cgu.0.rcgu.o): in function `std::io::stdio::Stderr::lock': std.bb3cc3eba9418e46-cgu.0:(.text._ZN3std2io5stdio6Stderr4lock17h0d9ce2d012147ea4E+0x99): undefined reference to `__atomic_load_8' /usr/lib/gcc/i486-pc-linux-gnu/13/../../../../i486-pc-linux-gnu/bin/ld: std.bb3cc3eba9418e46-cgu.0:(.text._ZN3std2io5stdio6Stderr4lock17h0d9ce2d012147ea4E+0xd9): undefined reference to `__atomic_store_8' /usr/lib/gcc/i486-pc-linux-gnu/13/../../../../i486-pc-linux-gnu/bin/ld: /var/tmp/portage/dev-lang/rust-1.81.0/work/rustc-1.81.0-src/build/i686-unknown-linux-gnu/stage1/lib/rustlib/i686-unknown-linux-gnu/lib/libstd-860e1f3ab53f533b.rlib(std-860e1f3ab53f533b.std.bb3cc3eba9418e46-cgu.0.rcgu.o): in function `std::sys::sync::once::futex::Once::call': std.bb3cc3eba9418e46-cgu.0:(.text.unlikely._ZN3std3sys4sync4once5futex4Once4call17h4e8b4349e3600450E+0x25f): undefined reference to `__atomic_load_8' /usr/lib/gcc/i486-pc-linux-gnu/13/../../../../i486-pc-linux-gnu/bin/ld: std.bb3cc3eba9418e46-cgu.0:(.text.unlikely._ZN3std3sys4sync4once5futex4Once4call17h4e8b4349e3600450E+0x2a2): undefined reference to `__atomic_store_8' /usr/lib/gcc/i486-pc-linux-gnu/13/../../../../i486-pc-linux-gnu/bin/ld: std.bb3cc3eba9418e46-cgu.0:(.text.unlikely._ZN3std3sys4sync4once5futex4Once4call17h4e8b4349e3600450E+0x32a): undefined reference to `__atomic_store_8' collect2: error: ld returned 1 exit status = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified = note: use the `-l` flag to specify native libraries to link = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib) I managed to compile Rust with i586. However resulting binary still contains illegal instructions. As far as I know CMOV is not part of i586 set. Perhaps the patch itself is not enough and CPU model has to be set in some other places too? k6 ~/rust # gdb --args rustc fibonaci.rs GNU gdb (Gentoo 14.2 vanilla) 14.2 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from rustc... (No debugging symbols found in rustc) (gdb) run Starting program: /usr/bin/rustc fibonaci.rs [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". [New Thread 0xaee26b40 (LWP 23686)] [New Thread 0xaeaffb40 (LWP 23687)] [New Thread 0xa9bffb40 (LWP 23688)] [New Thread 0xa93ffb40 (LWP 23689)] [New Thread 0xa87ffb40 (LWP 23690)] [Thread 0xa87ffb40 (LWP 23690) exited] [New Thread 0xa87ffb40 (LWP 23691)] Thread 7 "opt cgu.0" received signal SIGILL, Illegal instruction. [Switching to Thread 0xa87ffb40 (LWP 23691)] 0xb458c1a9 in ?? () from /usr/lib/rust/lib/librustc_driver-43167537af2404f0.so (gdb) x/i $pc => 0xb458c1a9: cmovne 0xc(%esp),%ecx (gdb) q k6 ~/rust # gdb --args cargo bench GNU gdb (Gentoo 14.2 vanilla) 14.2 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i486-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://bugs.gentoo.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from cargo... (No debugging symbols found in cargo) (gdb) run Starting program: /usr/bin/cargo bench [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. 0x01186e88 in ?? () (gdb) x/i $pc => 0x1186e88: cmovae %eax,%edi (gdb) Thanks again! That's very strange although not impossible for me to miss as QEMU can leak host instructions, even when disabled. I've been reunited with my Pentium mmx laptop so hopefully I'll have an update for everyone soon. Created attachment 904926 [details, diff]
crude additional patch to be able to compile for i586
Hi, It looks like something in vendor/cc-1.0.*/ sets its own compile flags. I created a crude patch and was able to build to i586 afterwards. https://bugs.gentoo.org/attachment.cgi?id=904926 Compile in QEMU - OK AMD K6-II: Install rust on real HW - OK Compile rust coreutils project on real HW - OK Resulting coreutils binary also works Tha(In reply to vanilkovy.puding from comment #72) > Hi, > It looks like something in vendor/cc-1.0.*/ sets its own compile flags. > I created a crude patch and was able to build to i586 afterwards. > > https://bugs.gentoo.org/attachment.cgi?id=904926 > > > Compile in QEMU - OK > AMD K6-II: > Install rust on real HW - OK > Compile rust coreutils project on real HW - OK > Resulting coreutils binary also works Thank you for testing and sorry it's taken so long to get around to, but this is a passion project rather than my main task in Gentoo. I've currently got this building to test with my Pentium MMX machine so will hopefully be moving back to review stage shortly. Can I please confirm your name and email also as I wish to make sure proper credit is given, as this is good work. (In reply to immolo from comment #73) > Can I please confirm your name and email also as I wish to make sure proper > credit is given, as this is good work. Hi immolo, I would like to remain uncredited. |
I cannot build gnome-base/librsvg on a i586 (Pentium MMX) as it has a dependency on Rust which requires the use of SSE2. Error: [block] !! The ebuild selected to satisfy "~dev-lang/rust-1.45.2[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_riscv_lp64d(-)?,abi_riscv_lp64(-)?,abi_riscv_ilp32d(-)?,abi_riscv_ilp32(-)?,abi_s390_32(-)?,abi_s390_64(-)?]" has unmet requirements. - dev-lang/rust-1.45.2::gentoo USE="-clippy -debug -doc -libressl (-miri) (-nightly) (-parallel-compiler) -rls -rustfmt (-system-bootstrap) (-system-llvm) -wasm" CPU_FLAGS_X86="-sse2" LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARM -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" The following REQUIRED_USE flag constraints are unsatisfied: x86? ( cpu_flags_x86_sse2 ) The above constraints are a subset of the following complete expression: any-of ( llvm_targets_AArch64 llvm_targets_AMDGPU llvm_targets_ARM llvm_targets_BPF llvm_targets_Hexagon llvm_targets_Lanai llvm_targets_Mips llvm_targets_MSP430 llvm_targets_NVPTX llvm_targets_PowerPC llvm_targets_RISCV llvm_targets_Sparc llvm_targets_SystemZ llvm_targets_WebAssembly llvm_targets_X86 llvm_targets_XCore ) miri? ( nightly ) parallel-compiler? ( nightly ) wasm? ( llvm_targets_WebAssembly ) x86? ( cpu_flags_x86_sse2 ) (dependency required by "virtual/rust-1.45.2::gentoo" [ebuild]) (dependency required by "gnome-base/librsvg-2.48.8::gentoo" [ebuild]) (dependency required by "x11-libs/gtk+-3.24.22::gentoo" [ebuild]) (dependency required by "app-crypt/gcr-3.36.0::gentoo[gtk]" [ebuild]) (dependency required by "gnome-base/gnome-keyring-3.36.0::gentoo" [ebuild]) (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) [/block]