|Summary:||dev-lang/rust: requires CPU_FLAGS_SSE2|
|Product:||Gentoo Linux||Reporter:||Alex Buell <alex.buell>|
|Component:||Current packages||Assignee:||Georgy Yakovlev <gyakovlev>|
|Severity:||normal||CC:||gnome, nbowler, O01eg, randy, rogerx.oss, rust, sam, solamour, tanekliang, Xeha|
|Package list:||Runtime testing required:||---|
Description Alex Buell 2020-09-11 19:09:59 UTC
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]
Comment 1 Sam James 2020-09-11 19:12:03 UTC
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 :(
Comment 2 Sam James 2020-09-11 19:14:01 UTC
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/
Comment 3 Georgy Yakovlev 2020-09-11 20:04:28 UTC
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.
Comment 4 Georgy Yakovlev 2020-09-11 20:05:27 UTC
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.
Comment 5 Ionen Wolkens 2020-09-11 20:18:01 UTC
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.
Comment 6 Alex Buell 2020-09-11 20:29:19 UTC
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 :-)
Comment 7 Georgy Yakovlev 2020-09-11 20:43:42 UTC
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)
Comment 8 Alex Buell 2020-09-12 13:03:54 UTC
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
Comment 9 Calvin Walton 2020-12-31 15:10:51 UTC
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.
Comment 10 Calvin Walton 2020-12-31 15:19:43 UTC
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.
Comment 11 Roger 2021-02-03 01:44:07 UTC
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.
Comment 12 Nick Bowler 2021-02-03 02:09:12 UTC
(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?
Comment 13 Roger 2021-02-03 19:28:52 UTC
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!
Comment 14 Roger 2021-02-05 23:15:19 UTC
gnome-base/librsvg-126.96.36.199.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.
Comment 15 Sam James 2021-02-05 23:37:41 UTC
(In reply to Roger from comment #14) > gnome-base/librsvg-188.8.131.52.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.
Comment 16 Roger 2021-02-06 01:37:15 UTC
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.
Comment 17 Roger 2021-02-06 03:31:53 UTC
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.
Comment 18 Sam James 2021-02-06 11:02:09 UTC
(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.
Comment 19 Roger 2021-02-08 03:11:19 UTC
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+.
Comment 20 Roger 2021-02-09 18:48:09 UTC
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.
Comment 21 Roger 2021-02-13 18:48:28 UTC
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.
Comment 22 Calvin Walton 2021-02-26 22:58:13 UTC
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
Comment 23 Roger 2021-03-08 23:23:51 UTC
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
Comment 24 Dylan Rush 2021-08-18 19:37:59 UTC
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.
Comment 25 Roger 2021-08-19 18:44:36 UTC
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.
Comment 26 Corey McGuire 2021-08-20 20:54:11 UTC
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.
Comment 27 Xeha 2021-08-21 10:20:57 UTC
(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
Comment 28 Kevin Brace 2021-09-17 22:03:46 UTC
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