The hard dependency of >firefox-53 on rust (and cargo) has been kind of a bummer for some time now if you don't have glibc as your systems libc. In case of musl, there are ebuilds for rust and cargo to build both of them successfully (the ebuilds can be found here https://github.com/smaeul/portage-overlay) It is not my project, but I asked the person to push or merge it to the gentoo tree, so to make it more officiall. However, even though the dependency on rust and cargo is satisfied with the ebuilds from the overlay and the rust compiler is up and working, firefox-55.0 compilation still breaks during src_configure, as it searches for the glibc rust target (--target=x86_64-unknown-linux-gnu) and hence cannot find the correct musl target (--target=x86_64-unknown-linux-musl). snipet from build.log checking for libffi > 3.0.9... yes checking MOZ_FFI_CFLAGS... -I/usr/lib/libffi-3.2.1/include checking MOZ_FFI_LIBS... -L/usr/lib/../lib64 -lffi checking for rustc... /usr/bin/rustc checking for cargo... /usr/bin/cargo checking rustc version... 1.19.0 checking cargo version... 0.20.0 DEBUG: Executing: `/usr/bin/rustc --crate-type staticlib --target=x86_64-unknown-linux-gnu -o /var/tmp/portage/www-client/firefox-55.0/temp/conftestqcCUms.rlib /var/tmp/portage/www-client/firefox-55.0/temp/conftests3GLTh.rs` DEBUG: The command returned non-zero exit status 101. DEBUG: Its error output was: DEBUG: | error[E0463]: can't find crate for `std` DEBUG: | | DEBUG: | = note: the `x86_64-unknown-linux-gnu` target may not be installed DEBUG: | DEBUG: | error: aborting due to previous error(s) DEBUG: | ERROR: Cannot compile for x86_64-gentoo-linux-musl with /usr/bin/rustc The target may be unsupported, or you may not have a rust std library for that target installed. Try: rustup target add x86_64-unknown-linux-gnu *** Fix above errors and then restart with\ "make -f client.mk build" make: *** [client.mk:383: configure] Error 1
Created attachment 488672 [details, diff] trivial patch to fix this The patch attached works around the problem at the cost of breaking glibc builds. Any ideas how to solve this properly?
Until musl has support for rust/cargo in main gentoo I will not continue to support it via the mozilla overlay. Your patch is also incorrect and would need to be applied based on useflag which I am not interested in either as it is not upstreamable.
Ehr, the patch is of course not upstreamable. Neither is it complete, but it is correct for the case that a user on a amd64-musl profile runs into the above described failure in src_configure. The ebuild has epatch_user, so let's just keep this open. I don't know if mozilla accepts bugs from new bugzilla accounts without a patch, but I'm going to open a bug upstream.
(In reply to tt_1 from comment #3) > Ehr, the patch is of course not upstreamable. Neither is it complete, but it > is correct for the case that a user on a amd64-musl profile runs into the > above described failure in src_configure. > > The ebuild has epatch_user, so let's just keep this open. I don't know if > mozilla accepts bugs from new bugzilla accounts without a patch, but I'm > going to open a bug upstream. Please do not reopen. They can search for your bug report without it being open. When rust is supported in the tree officially for musl that is when musl support will be added back into the tree, I am maintaining all musl patches already in the patchset just for those who are using custom overlays. Feel free to apply it via /etc/portage/patches/www-client/firefox
58.0_beta8 is in the mozilla overlay, it no longer requires patching.
