dev-lang/rust-1.47.0 add gentoo vendor target but don't build std for those target. The default target in rust is still x86_64-unknown-linux-musl. $ rustc --print target-libdir /usr/lib/rust/1.47.0/lib/rustlib/x86_64-unknown-linux-musl/lib And x86_64-gentoo-linux-musl is in target list of rust: rustc --print target-list | grep musl aarch64-gentoo-linux-musl aarch64-unknown-linux-musl arm-unknown-linux-musleabi arm-unknown-linux-musleabihf armv5te-unknown-linux-musleabi armv7-gentoo-linux-musleabihf armv7-unknown-linux-musleabi armv7-unknown-linux-musleabihf hexagon-unknown-linux-musl i586-unknown-linux-musl i686-gentoo-linux-musl i686-unknown-linux-musl mips-unknown-linux-musl mips64-unknown-linux-muslabi64 mips64el-unknown-linux-muslabi64 mipsel-unknown-linux-musl powerpc-gentoo-linux-musl powerpc-unknown-linux-musl powerpc64-gentoo-linux-musl powerpc64-unknown-linux-musl powerpc64le-gentoo-linux-musl powerpc64le-unknown-linux-musl thumbv7neon-unknown-linux-musleabihf x86_64-gentoo-linux-musl x86_64-unknown-linux-musl In firefox's rust.configure, x86_64-gentoo-linux-musl is chosen as the build target (base on CHOST), and failed because there is no std for this target. We should disable those gentoo vendor target until https://bugs.gentoo.org/747760 is useable or patch rust.configure to choose x86_64-unknown-linux-musl Reproducible: Always Actual Results: 0:14.23 checking for rustc... /usr/bin/rustc 0:14.23 checking for cargo... /usr/bin/cargo 0:14.32 checking rustc version... 1.47.0-nightly 0:14.32 checking cargo version... 1.47.0 0:14.46 checking for rust target triplet... 0:14.46 DEBUG: Creating `/tmp/portage/www-client/firefox-81.0.2/temp/conftest6hcd0hy_.rs` with content: 0:14.46 DEBUG: | pub extern fn hello() { println!("Hello world"); } 0:14.46 DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib --target=x86_64-gentoo-linux-musl -o /tmp/portage/www-client/firefox-81.0.2/temp/conftest99l1dfs8.rlib /tmp/portage/www-client/firefox-81.0.2/temp/conftest6hcd0hy_.rs` 0:14.46 DEBUG: The command returned non-zero exit status 1. 0:14.46 DEBUG: Its error output was: 0:14.46 DEBUG: | error[E0463]: can't find crate for `std` 0:14.46 DEBUG: | | 0:14.46 DEBUG: | = note: the `x86_64-gentoo-linux-musl` target may not be installed 0:14.46 DEBUG: | 0:14.46 DEBUG: | error: aborting due to previous error 0:14.46 DEBUG: | 0:14.46 DEBUG: | For more information about this error, try `rustc --explain E0463`. 0:14.46 ERROR: Cannot compile for x86_64-gentoo-linux-musl with /usr/bin/rustc 0:14.46 The target may be unsupported, or you may not have 0:14.46 a rust std library for that target installed. Try: 0:14.46 0:14.46 rustup target add x86_64-gentoo-linux-musl 0:14.46 0:14.51 *** Fix above errors and then restart with\ 0:14.51 "./mach build" 0:14.51 gmake: *** [client.mk:115: configure] Error 1
yes, it's work in progress and not a mistake. I've added them so rust knows the target definitions. bootstrap from -unknown- to -gentoo- still does not work, even with json target specification and I will tackle it as I have more time, probably by providing bootstrap tarballs.
and since firefox does not work with ::gentoo rust on musl, just use ::smaeul for now, as usual. it has real gentoo target with std. so nothing really changed. but work in progress on that.
I'm also hitting this still on a new build with musl. Rustup is not found after rust is installed so I'm not sure how to proceed. I also do not need firefox but a basic world update after getting the kernel and grub built is pulling it in.Yo
Since normal rust is now working even for musl, we dropped our musl target patch with 91.4.0esr and 95.0 after consulting with musl patch. Fixed rust should be available in ::gentoo shortly.
Created attachment 813445 [details, diff] rust-target-respect-override.patch See attached rust-target-respect-override.patch. Thanks to gyakovlev, worked out a proper solution for this. It allows a successful build with dev-lang/rust + www-client/firefox-105.0. Tested on glibc as well with no interference. It'll need a change in the ebuild too: ``` --- a/www-client/firefox/firefox-105.0.ebuild +++ b/www-client/firefox/firefox-105.0.ebuild @@ -38,7 +38,7 @@ MOZ_P_DISTFILES="${MOZ_PN}-${MOZ_PV_DISTFILES}" inherit autotools check-reqs desktop flag-o-matic gnome2-utils linux-info \ - llvm multiprocessing pax-utils python-any-r1 toolchain-funcs \ + llvm multiprocessing pax-utils python-any-r1 rust-toolchain toolchain-funcs \ virtualx xdg MOZ_SRC_BASE_URI="https://archive.mozilla.org/pub/${MOZ_PN}/releases/${MOZ_PV}" @@ -580,6 +580,8 @@ # Make cargo respect MAKEOPTS export CARGO_BUILD_JOBS="$(makeopts_jobs)" + export RUST_TARGET=$(rust_abi) + # Make LTO respect MAKEOPTS sed -i \ -e "s/multiprocessing.cpu_count()/$(makeopts_jobs)/" \ ``` If you want, feel free to only export it on musl or something.
Inheriting rust-toolchain enables multilib for Firefox breaking it (on a multilibbed system at least). I've added the patch in https://dev.gentoo.org/~juippis/mozilla/patchsets/firefox-105-patches-02j.tar.xz and tested with your changes and ABI_X86="-32" and it works. If you can figure out a way to disable multilib, go ahead and commit your changes while also bumping the patch set. --- /tmp/firefox-105.0.ebuild 2022-09-22 10:43:32.554676715 -0000 +++ ./firefox-105.0.ebuild 2022-09-22 09:52:29.218883003 -0000 @@ -3,7 +3,7 @@ EAPI=8 -FIREFOX_PATCHSET="firefox-105-patches-01j.tar.xz" +FIREFOX_PATCHSET="firefox-105-patches-02j.tar.xz" LLVM_MAX_SLOT=14 @@ -38,7 +38,7 @@ MOZ_P_DISTFILES="${MOZ_PN}-${MOZ_PV_DISTFILES}" inherit autotools check-reqs desktop flag-o-matic gnome2-utils linux-info \ - llvm multiprocessing pax-utils python-any-r1 toolchain-funcs \ + llvm multiprocessing pax-utils python-any-r1 rust-toolchain toolchain-funcs \ virtualx xdg MOZ_SRC_BASE_URI="https://archive.mozilla.org/pub/${MOZ_PN}/releases/${MOZ_PV}" @@ -580,6 +580,9 @@ # Make cargo respect MAKEOPTS export CARGO_BUILD_JOBS="$(makeopts_jobs)" + # Respect RUST_TARGET, #748849 + export RUST_TARGET=$(rust_abi) + # Make LTO respect MAKEOPTS sed -i \ -e "s/multiprocessing.cpu_count()/$(makeopts_jobs)/" \
I guess using MULTILIB_COMPAT is the *cleanest* way (that I can think of at least) but it still leaves that ABI_X86="(64)" to emerge output...
let's maybe hold off the patch, COMPAT thing seems a bit off tbh. I wanted to redo that eclass for a LONG time, maybe I'll just move it to separate small rust_targets.eclass without multilib in it. alternative solution is to (pseudobash) basically if elibc_musl and chost == *-gentoo-*; then RUST_TARGET=${CHOST/-gentoo-/-unknown-}; fi and third and hardest solution is to merge a variant of https://github.com/gentoo/gentoo/pull/20727 which gets rid rust of multilib abi flags and implements gcc-like USE=multilib
and maybe I can make rust install -gentoo- target too. just need time to poke it.
(In reply to Georgy Yakovlev from comment #8) > let's maybe hold off the patch, COMPAT thing seems a bit off tbh. > > I wanted to redo that eclass for a LONG time, maybe I'll just move it to > separate small rust_targets.eclass without multilib in it. > This is my preference for now.
