Summary: | www-client/firefox-110.0: SANDBOX ACCESS VIOLATION with USE="pgo" | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | sqrtd <v> |
Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | flyser42, StormByte |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
emerge --info output
full build.log |
Description
sqrtd
2023-02-21 20:29:39 UTC
Created attachment 853522 [details]
emerge --info output
Could you upload the full build.log please? You can use "xz -9" to compress it. Created attachment 853888 [details]
full build.log
So I was able to build firefox with your use flags on a normal glibc system. Then I spent a day setting up a musl container... just to realize pgo is use.masked for firefox in musl. So by that definition pgo won't work with musl. However your error doesn't seem to be related to musl, but I'd rather blame -dbus and your system overall instead. If you want to try, add: addpredict /dev/snd to line 552 in the ebuild. To clarify, you want to edit this: # May need a wider addpredict when using wayland+pgo. addpredict /dev/dri into this: # May need a wider addpredict when using wayland+pgo. addpredict /dev/dri addpredict /dev/snd (Again, I was able to compile firefox with -dbus +pgo +lto so just guessing here) I've just compiled Firefox with your suggested fix with both PGO & clang on musl which are masked, and it built successfully, so is there any reason for it to still be masked? I've had both unmasked for 1–2 months without even noticing until this issue came up and like you said it doesn't seem related to musl, and Alpine also seems to use PGO (not sure about clang) when building Firefox on amd64 (https://git.alpinelinux.org/aports/tree/community/firefox/APKBUILD#n614). Thank you very much for your help and suggested fix and sorry if I wasted any of your time. The issue was/is that building with clang[-default-libcxx] (or otherwise not passing -stdlib=libc++ or whatever it is) would fail. I haven't verified that now works. (In reply to sqrtd from comment #5) > I've just compiled Firefox with your suggested fix with both PGO & clang on > musl which are masked, and it built successfully, so is there any reason for > it to still be masked? I've had both unmasked for 1–2 months without even > noticing until this issue came up and like you said it doesn't seem related > to musl, and Alpine also seems to use PGO (not sure about clang) when > building Firefox on amd64 > (https://git.alpinelinux.org/aports/tree/community/firefox/APKBUILD#n614). > > Thank you very much for your help and suggested fix and sorry if I wasted > any of your time. Just for the record, they use also clang/clang++ to compile: https://git.alpinelinux.org/aports/tree/community/firefox/APKBUILD#n639 While this bug may not be fixed (relate to -dbus), pgo is now available on musl with commit d48fc6e32f86ef142c73c7c546d23d607334319e Our "current" versions should have pretty wide sandbox relaxation when using pgo. 115esr may not work, but it's probably having its last version bump this week so I'm not going to spend time relaxing the sandbox paths there. 128esr and 130rapid should be okay, even in musl. |