Summary: | www-client/firefox-84.0.1-r1 - /usr/lib/llvm/11/lib/libclang.so.11 could not be opened: Dynamic loading not supported"', /var /tmp/portage/www-client/firefox-84.0.1-r1/work/firefox-84.0.1/third_party/rust/bindgen/src/lib.rs:1956:31 (on musl) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | ernsteiswuerfel <erhard_f> |
Component: | Current packages | Assignee: | Gentoo musl team <musl> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | ionen, mozilla, philipp.ammann, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://github.com/rust-lang/compiler-team/issues/422 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 430702 | ||
Attachments: |
build.log.xz
emerge --info |
Description
ernsteiswuerfel
2021-01-05 23:45:00 UTC
Created attachment 681364 [details]
emerge --info
please add emerge -pv firefox to maybe reveal use of lto or pgo stuff, thanks (In reply to tt_1 from comment #2) > please add emerge -pv firefox to maybe reveal use of lto or pgo stuff, thanks From the build.log: USE: abi_x86_64 amd64 clang dbus elibc_musl gmp-autoupdate hwaccel kernel_linux l10n_de openh264 pulseaudio system-av1 system-harfbuzz system-icu system-jpeg system-libevent system-libvpx system-webp userland_GNU Haven't tried firefox with musl myself, so can't say much. # emerge -pv firefox These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N #] www-client/firefox-84.0.1-r1:0/84::gentoo USE="clang dbus gmp-autoupdate hwaccel openh264 pulseaudio system-av1 system-harfbuzz system-icu system-jpeg (system-libevent) system-libvpx system-webp -debug -eme-free -geckodriver -hardened -jack -lto -pgo -screencast (-selinux) -wayland -wifi" L10N="de -ach -af -an -ar -ast -az -be -bg -bn -br -bs -ca -ca-valencia -cak -cs -cy -da -dsb -el -en-CA -en-GB -eo -es-AR -es-CL -es-ES -es-MX -et -eu -fa -ff -fi -fr -fy -ga -gd -gl -gn -gu -he -hi -hr -hsb -hu -hy -ia -id -is -it -ja -ka -kab -kk -km -kn -ko -lij -lt -lv -mk -mr -ms -my -nb -ne -nl -nn -oc -pa -pl -pt-BR -pt-PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv -ta -te -th -tl -tr -trs -uk -ur -uz -vi -xh -zh-CN -zh-TW Hmm, have seen other bugs that it won't build on musl in it's current state... I will add this to the blocker in sake of completeness, but if this issue is already known just resolve it as duplicate. I've read firefox-84.0.1+gcc+musl builds, so new USE=clang default may be an issue for musl users (haven't tried myself). Taking the liberty to assign to musl@ because, seeing previous bugs, it appears preferred by the Mozilla team. Please set RUSTFLAGS=-Ctarget-feature=-crt-static and try again. See also: https://github.com/rust-lang/rust-bindgen/issues/1867 Yes, it seems to be this rust issue. I 'solved' it by using rust-1.47.0-r1 from smaeul overlay. Firefox builds fine and runs ok then. This solved another issue I was having, building USE="clang jit" spidermonkey-78.6.0. Does not build with regular rust but with the smaeul one. I can confirm the issue still exists with Rust 1.55, Clang/LLVM 12 and Firefox 91.0.2. ah yeah, just hit the same Bug when cross compiling firefox-91.3.0 from amd64-musl host to aarch64-musl target. Anarchy, Chewi and I have been working recently on this. If all goes well, patches will be available tomorrow. Works so far in x86_64; aarch64 being tested as I write this. (In reply to #!/yeehaw from comment #10) > Anarchy, Chewi and I have been working recently on this. If all goes well, > patches will be available tomorrow. Works so far in x86_64; aarch64 being > tested as I write this. This would be really cool! So a regular Firefox build with rust::gentoo is possible now? Will test that on ppc64 too of course. ;) Right now, I have an x86_64-musl VM and an aarch64-musl pi3b that run Firefox 94.0.2 built with rust-1.56.1 but I cross-compile, and in order for my patches to not interfere with glibc builds some changes were needed (this is where Anarchy and Chewi saved the day, as well as noticing another issue while compiling natively, which I wasn't affected by). These new patches are being used to compile/test Firefox on natively compiled aarch64 today. It's Thanksgiving in the USA today though. re: ppc[64] more testing will be needed, and devs with the needed hardware to test on find that rust updates are a somewhat daunting task (which I agree with). So YMMV for ppc[64]. This said, my main (secret, for now) project is still a work in progress, but could possibly lead to cross-compiling Firefox for ppc[64] on a different cpu architecture. More details to come, but because I do not have the ppc[64] hardware to test results on, testers/helpers/contributors will be needed for that to happen. For now, after my next code "release", which should be in a week (but it'll be ready when it's ready, like the saying goes :P), perhaps whoever is interested in trying can join #gentoo-arm to collaborate on ppc[64] targets, after taking time to understand how to with my help. Seems at some point of time the existing upstream rust targets will be dynamically linked, just as their glibc-counterparts: https://github.com/rust-lang/compiler-team/issues/422 Meanwhile Firefox and Firefox ESR build fine on amd64 when dev-lang/rust/rust::musl from the musl overlay is used (which is pointed to in the Wiki). This will have to be resolved upstream. |