| Summary: | www-client/firefox: the `x86_64-gentoo-linux-musl` target may not be installed | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | 12101111 <w12101111> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | njd.dev, opal, sam |
| Priority: | Normal | Keywords: | PATCH, PullRequest |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=747760 https://bugs.gentoo.org/show_bug.cgi?id=836226 https://bugs.gentoo.org/show_bug.cgi?id=779178 https://bugs.gentoo.org/show_bug.cgi?id=915651 https://github.com/gentoo/gentoo/pull/35268 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | rust-target-respect-override.patch | ||
|
Description
12101111
2020-10-14 07:49:45 UTC
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. |
