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. |
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]