Created attachment 678538 [details] build.log Hi. This package claims to support x32 ABI but there is no rust-1.47.0-x32-unknown-linux-gnu.tar.xz in /usr/portage/disfiles.
I can confirm it is still broken with 1.52.1 as well as dev-lang/rust for x32
Reproducible with dev-lang/rust-1.53.0:stable: > * Package: dev-lang/rust-1.53.0 > * Repository: gentoo > * Maintainer: gyakovlev@gentoo.org rust@gentoo.org > * USE: abi_x86_64 abi_x86_x32 amd64 cpu_flags_x86_sse2 elibc_glibc kernel_linux llvm_targets_X86 userland_GNU > * FEATURES: network-sandbox preserve-libs sandbox userpriv usersandbox > * Checking for at least 11520 MiB disk space at "/var/tmp/portage/dev-lang/rust-1.53.0/temp" ... > [ ok ] > * Using python3.9 to build > /var/tmp/portage/dev-lang/rust-1.53.0/temp/environment: line 3985: /var/tmp/portage/dev-lang/rust-1.53.0/work/rust-1.52.0-x86_64-pc-linux-gnux32/install.sh: No such file or directory > * ERROR: dev-lang/rust-1.53.0::gentoo failed (prepare phase): > * (no error message) > * > * Call stack: > * ebuild.sh, line 127: Called src_prepare > * environment, line 3985: Called die > * The specific snippet of code: > * "${WORKDIR}/${rust_stage0}"/install.sh --disable-ldconfig --without=rust-docs --destdir="${rust_stage0_root}" --prefix=/ || die; > * > * If you need support, post the output of `emerge --info '=dev-lang/rust-1.53.0::gentoo'`, > * the complete build log and the output of `emerge -pqv '=dev-lang/rust-1.53.0::gentoo'`. > * The complete build log is located at '/var/tmp/portage/dev-lang/rust-1.53.0/temp/build.log'. > * The ebuild environment file is located at '/var/tmp/portage/dev-lang/rust-1.53.0/temp/environment'. > * Working directory: '/var/tmp/portage/dev-lang/rust-1.53.0/work/rustc-1.53.0-src' > * S: '/var/tmp/portage/dev-lang/rust-1.53.0/work/rustc-1.53.0-src'
The upstream rust binary distribution *does* support x32 (x86_64-unknown-linux-gnux32) but as a target only, and requires the x32 rust-std (rustlib) component to be installed. The toolchain itself is amd64 only. For the purpose of bootstrapping a native x32 Rust toolchain, this enough. Patches follow...
Created attachment 776612 [details, diff] rust-bin ebuild patch adding x32 target rustlib
Created attachment 776615 [details, diff] rust eclass patch to add x32 triple mapping
Created attachment 776618 [details, diff] WIP patch to build native x32 rust toolchain This is WIP because -system-bootstrap isn't complete. It currently only works with system-bootstrap, although both dev-lang/rust-bin (amd64) and dev-lang/rust (x32) both work to bootstrap.
(In reply to Steven Newbury from comment #6) > Created attachment 776618 [details, diff] [details, diff] > WIP patch to build native x32 rust toolchain > > This is WIP because -system-bootstrap isn't complete. It currently only > works with system-bootstrap, although both dev-lang/rust-bin (amd64) and > dev-lang/rust (x32) both work to bootstrap. Also, only tested with system-llvm.
(In reply to Steven Newbury from comment #6) > Created attachment 776618 [details, diff] [details, diff] > WIP patch to build native x32 rust toolchain > > This is WIP because -system-bootstrap isn't complete. It currently only > works with system-bootstrap, although both dev-lang/rust-bin (amd64) and > dev-lang/rust (x32) both work to bootstrap. To get !system-boostrap working requires adding the x32 rustlib matching the rust release used for internal bootstrapping as I did for rust-bin.
Created attachment 776630 [details, diff] rust-bin ebuild patch adding x32 target rustlib Accidentally attached the wrong version.
Created attachment 777059 [details, diff] rust-bin ebuild patch adding x32 target rustlib Fixed bug
Created attachment 777062 [details, diff] rust-bin ebuild patch adding x32 target rustlib Forgot to mark obsolete
Created attachment 777068 [details, diff] rust-bin ebuild patch adding x32 target rustlib Apologies, this version works for both when x32 is multilib_is_native and when it isn't. Suffering from apparent brain failure.
I've updated my modified ebuilds for rust-1.77.1. Is there any chance of this bug getting addressed? Gentoo X32 is actually working very well right now, at least for relatively simple systems but rust is becoming increasingly important. It is one of the few upstreams to actually support abi-x32 so it doesn't really make sense to not have this bug fixed.
There is one outstanding issue with bootstrapping from the 64-bit amd64 rustc, the (Canadian) cross build requires 64-bit liblzma. What would be the best way off adding this dependency only for bootstrapping? With USE=system-bootstrap I suppose app-arch/xz-utils[abi_x86_64] could be added as an RDEPEND to dev-lang/rust-bin[abi_x86_x32]?
I'll update the ebuilds this weekend.
I've tested the rust-bin with a slightly edited patch to make it work for 1.77.1 and have at least confirmed this works at this point. When the updated ebuilds are done I will look into the rust ebuild as well.
Created attachment 894556 [details] rust ebuild supporting bootstrapping x32 from amd64 It requires system-bootstrap from rust-bin or from already merged x32 rustc.
Created attachment 894557 [details] rust-bin ebuild updated to latest version
The above rust ebuilds require the eclass patch for the x32 rust triple.
Would it be better if I attached patches of the ebuilds instead as I did previously?
Thanks for the updated ebuilds. I have spent the last week testing these and have confirmed the rust-bin works perfectly however there is issues with compiling it on a x32 system. I've spoke to the Rust project in Gentoo about my results and they are happy for you to make a PR for a rebased rust-bin ebuild for 1.78.0 (do check if 1.79.0 is out though as that release is incoming any day now). If you need help with this then please ping me in #gentoo-rust but please be aware you might need to wait a bit for me to reply and the channel isn't actively monitored so it might take an hour for us to get back to you. Once again thanks for the work you have put into keeping x32 alive.
*** Bug 947673 has been marked as a duplicate of this bug. ***
(In reply to immolo from comment #21) > Thanks for the updated ebuilds. I have spent the last week testing these and > have confirmed the rust-bin works perfectly however there is issues with > compiling it on a x32 system. > > I've spoke to the Rust project in Gentoo about my results and they are happy > for you to make a PR for a rebased rust-bin ebuild for 1.78.0 (do check if > 1.79.0 is out though as that release is incoming any day now). > > If you need help with this then please ping me in #gentoo-rust but please be > aware you might need to wait a bit for me to reply and the channel isn't > actively monitored so it might take an hour for us to get back to you. > > Once again thanks for the work you have put into keeping x32 alive. Sorry for disappearing. I have had some personal issues, then a badly timed NVMe failure! I'm currently building a new x32 install on an E2-1800, it's really good candidate for x32! So obviously, Rust is pretty much needed today, so I'm going to get this rebased onto the current portage Rust releases.
(In reply to immolo from comment #21) > Thanks for the updated ebuilds. I have spent the last week testing these and > have confirmed the rust-bin works perfectly however there is issues with > compiling it on a x32 system. > > I've spoke to the Rust project in Gentoo about my results and they are happy > for you to make a PR for a rebased rust-bin ebuild for 1.78.0 (do check if > 1.79.0 is out though as that release is incoming any day now). > > If you need help with this then please ping me in #gentoo-rust but please be > aware you might need to wait a bit for me to reply and the channel isn't > actively monitored so it might take an hour for us to get back to you. > > Once again thanks for the work you have put into keeping x32 alive. I don't suppose you remember what the issue was with the native x32 build? It was working for me at the time. Did you have the eclass with the added target?
I don't sorry, I'd be happy to retest with the updated fixes as I've meant to rebase to the new rust changes made over the last year, however not found the time to so far.
(In reply to immolo from comment #25) > I don't sorry, I'd be happy to retest with the updated fixes as I've meant > to rebase to the new rust changes made over the last year, however not found > the time to so far. I'm currently emerging dev-lang/rust-1.85-r1 with my changes using the rust-bin with x32 target support. I did need to bypass the dependency check since it seemed to want to only bootstrap with dev-lang/rust-1.85-r1, but it's doing okay so far... If it all goes okay, I'll see about making a PR.
(In reply to Steven Newbury from comment #26) > (In reply to immolo from comment #25) > > I don't sorry, I'd be happy to retest with the updated fixes as I've meant > > to rebase to the new rust changes made over the last year, however not found > > the time to so far. > > I'm currently emerging dev-lang/rust-1.85-r1 with my changes using the > rust-bin with x32 target support. I did need to bypass the dependency check > since it seemed to want to only bootstrap with dev-lang/rust-1.85-r1, but > it's doing okay so far... > > If it all goes okay, I'll see about making a PR. Okay. Hit a problem. Looks like at least llvm19 is broken when built with x32, which may explain why I can't get the the mesa r600g driver working either. I'm going to make another x32 system on different hardware since the E2-1800 takes an insanely long time to build anything! At least the rustc is generating a good backtrace, maybe I can figure out where the problem lies.
(In reply to Steven Newbury from comment #27) > (In reply to Steven Newbury from comment #26) > > (In reply to immolo from comment #25) > > > I don't sorry, I'd be happy to retest with the updated fixes as I've meant > > > to rebase to the new rust changes made over the last year, however not found > > > the time to so far. > > > > I'm currently emerging dev-lang/rust-1.85-r1 with my changes using the > > rust-bin with x32 target support. I did need to bypass the dependency check > > since it seemed to want to only bootstrap with dev-lang/rust-1.85-r1, but > > it's doing okay so far... > > > > If it all goes okay, I'll see about making a PR. > > Okay. Hit a problem. Looks like at least llvm19 is broken when built with > x32, which may explain why I can't get the the mesa r600g driver working > either. > > I'm going to make another x32 system on different hardware since the E2-1800 > takes an insanely long time to build anything! At least the rustc is > generating a good backtrace, maybe I can figure out where the problem lies. Successful build on a new x32 stage3 after emerge -e @system with -march=native (bdver2). It may be an issue with my E2-1800 Gentoo install or with btver1 specific codegen or CFLAGS combination. I'll try building it on the E2-1800 without -march=native. (Really not ideal for the E2-1800!) @immolo, I wonder if you encountered a similar build failure when you tested it? I think it can be assumed that the ebuilds are working correctly. There is a caveat though, the rust-bin will default to LP64 even with the x32 component added, which means it's a good idea to just use it for bootstrapping the native dev-lang/rust rather than as the system rust! Perhaps I should add a note at the end o the rust-bin emerge to that effect?
Now it's working again, I'd like to discuss the implication of what I noted above: dev-lang/rust-bin[abi_x86_x32,abi_x86_64] (which is the required combination) will result in a rustc which defaults to the LP64 target. This means it shouldn't be used to build x32 rust packages, *unless* portage adds the target triple to the default system RUSTFLAGS. After using this to bootstrap a native dev-lang/rust, the resulting rustc *will* default to ILP32 while still supporting LP64 with an appropriate target triple. How should this be handled? It would be inappropriate to merge my ebuild modifications if an emerge must be interrupted after installing rust-bin on x32, perhaps it's enough to trigger dev-lang/rust[abi_x86_x32] as a post dependency? Then again, it's arguably still an improvement. Thoughts?
Seems we should add something to cargo.eclass based on CHOST?
(In reply to Sam James from comment #30) > Seems we should add something to cargo.eclass based on CHOST? Yes, just setting the target triple according to CHOST would probably work. At least for everything using Cargo. Does anything use rustc directly?
(In reply to Steven Newbury from comment #31) > (In reply to Sam James from comment #30) > > Seems we should add something to cargo.eclass based on CHOST? > > Yes, just setting the target triple according to CHOST would probably work. > At least for everything using Cargo. Does anything use rustc directly? Of course, it also needs the x86_64-unknown-linux-gnux32 rust_abi added to rust-toolchain.eclass.
(In reply to Steven Newbury from comment #31) > (In reply to Sam James from comment #30) > > Seems we should add something to cargo.eclass based on CHOST? > > Yes, just setting the target triple according to CHOST would probably work. > At least for everything using Cargo. Does anything use rustc directly? Things using Meson will use rustc directly, we may need to figure something out there. But anything using rustc directly will have problems on musl too (the static thing).
