Dump of #gentoo-mozilla from a little while ago: """ [2023-05-31T19:09:30+0100] <+sam_> hm [2023-05-31T19:09:45+0100] <+sam_> so clang crashed when building FF [2023-05-31T19:09:51+0100] <+sam_> but the interesting bit here is the mix of LLVM 15 + 17 [2023-05-31T19:09:55+0100] <+sam_> I'm wondering what picked 17 [2023-05-31T19:10:22+0100] <+sam_> my system `clang` is 17, so I'm guessing that's it [2023-05-31T19:10:42+0100] <+sam_> I thought the firefox ebuild enforced a matching clang though [2023-05-31T19:10:46+0100] <+sam_> http://sprunge.us/zI6G6k [2023-05-31T19:11:28+0100] <+sam_> (CTRL-F " 6:51.76 clang-15: error: unable to execute command: Aborted (core dumped)") [2023-05-31T19:19:27+0100] <+sam_> hm [2023-05-31T19:19:39+0100] <+sam_> why doesn't the firefox ebuild use llvm.eclass, again? [2023-05-31T19:19:51+0100] <+sam_> llvm.eclass has llvm_fix_tool_path for this purpose :) [2023-05-31T19:20:05+0100] <+sam_> oh it does [2023-05-31T19:20:10+0100] <+sam_> so why isn't llvm_fix_tool_path doing what I want [2023-05-31T19:22:19+0100] <+sam_> ah, now I get it [2023-05-31T19:22:35+0100] <+sam_> llvm_pkg_setup doesn't call it for CC and CXX, it treats them differently [2023-05-31T19:22:47+0100] <+sam_> it does llvm_fix_clang_version instead which is interesting [2023-05-31T19:23:07+0100] <+sam_> i'm still pretty lost here [2023-05-31T19:23:12+0100] <+sam_> i don't get what's actually pulling in 17 [2023-05-31T19:25:24+0100] <+sam_> running the crashing commamd manually is fine [2023-05-31T19:26:54+0100] <+sam_> ok, reproduced [2023-05-31T19:26:55+0100] <+sam_> it was lld [2023-05-31T19:29:53+0100] <+sam_> ah!! [2023-05-31T19:29:57+0100] <+sam_> I don't have lld:15 installed [2023-05-31T19:30:31+0100] <+sam_> so for USE=clang at least, I think we need to depend on sys-devel/lld:${LLVM_SLOT} [2023-05-31T19:30:53+0100] <+sam_> the mold thing is confusing it [2023-05-31T19:31:38+0100] <+sam_> thanks for listening to the ramblings [2023-05-31T19:31:43+0100] <+sam_> tl;dr: the || ( ... ) dep with mold might cause problems """ The || ( lld mold ) dep in the ebuild means that if mold is installed, there's no obligation for lld for the chosen slot to be installed, so e.g. Clang 15 may be used but with a newer lld (in my case: clang 15, lld 17) which can cause problems during the build (segfaulted in my case). In another case on a different machine, I've had pkg_setup fail as well.
Created attachment 863804 [details] build.log.xz
juippis did commit a fix for >=113.0.2 in https://gitweb.gentoo.org/repo/gentoo.git/commit/www-client/firefox?id=8c6e9d78faa844dedd9fd879f297cc3d92dc8320, so I think this is why I now get the pkg_setup failure on one machine rather than the build failure
Yeah, this is a hard one to crack. I really don't want to add a "mold" use flag, nor do I want to construct some mega complicated check that'll then most likely break in other ways. I think we should always depend on sys-devel/lld:${LLVM_SLOT} but allow mold to be chosen instead with $(tc-ld-is-mold). So drop the dependency on mold, but have it available via configure. I believe it's not possible to run lld'ess system even with systemwide clang+mold?
(In reply to Joonas Niilola from comment #3) > Yeah, this is a hard one to crack. I really don't want to add a "mold" use > flag, nor do I want to construct some mega complicated check that'll then > most likely break in other ways. > > I think we should always depend on sys-devel/lld:${LLVM_SLOT} but allow mold > to be chosen instead with $(tc-ld-is-mold). So drop the dependency on mold, > but have it available via configure. > Sounds good to me. > I believe it's not possible to run lld'ess system even with systemwide > clang+mold? Yeah, I doubt it is, and if it is, it's.. unwise.
Updated on 117.0. Will sync with ESR and Thunderbird while bumping them.
