Firefox is no longer building, and none of the suggested fixes really work. This happened before with 12 and 11 (ref: https://www.reddit.com/r/Gentoo/comments/o2u4wz/cannot_build_firefox_anymore/) Reproducible: Always
Created attachment 770465 [details] build.log
Please provide emerge --info and change the bug status back to UNCONFIRMED.
Created attachment 770468 [details] emerge --info Here you go, mate.
Yeah there's really no way to work this over with ebuilds. The error message attempts to be clear enough. Basically you'll have to make sure your lld and rust are built with the same llvm+clang toolchain stack. Your rust{-bin} is built with llvm:14 + clang:14, so now you have to rebuild your sys-devel/lld with those as well. Emerging lld-14.0.0 should do it. eselect rust list (make sure 1.60 is selected) emerge -1av =sys-devel/lld-14.0.0 emerge -av firefox:rapid If that doesn't help, make sure you have llvm:14 and clang:14 installed. emerge -1av llvm:14 clang:14 =sys-devel/lld-14.0.0 emerge -av firefox:rapid
It's exacerbated by the lack of revbump for Firefox 99 - it doesn't allow upgrading LLD unless you re-emerge Firefox manually. Revbumping it would've helped but the forthcoming 99.0.1 bump will mean we don't need to.
(In reply to Sam James from comment #5) > helped but the forthcoming 99.0.1 bump will mean we don't need to. Yep, good point, I'm currently doing test runs for 99.0.1 and if everything goes well, it's gonna be pushed in ~3-4 hours. > It's exacerbated by the lack of revbump for Firefox 99 - it doesn't allow > upgrading LLD unless you re-emerge Firefox manually. Revbumping it would've I don't see how really, since the llvm-lld chain is BDEPEND-only. It's because you emerge a newer rust{-bin} but you can still have llvm:13 and lld-13 installed. If you use system-wide gcc, but clang+lto for firefox, you're not updating lld along with system updates.
(In reply to Joonas Niilola from comment #6) > (In reply to Sam James from comment #5) > > helped but the forthcoming 99.0.1 bump will mean we don't need to. > > Yep, good point, I'm currently doing test runs for 99.0.1 and if everything > goes well, it's gonna be pushed in ~3-4 hours. > > > It's exacerbated by the lack of revbump for Firefox 99 - it doesn't allow > > upgrading LLD unless you re-emerge Firefox manually. Revbumping it would've > > I don't see how really, since the llvm-lld chain is BDEPEND-only. It's > because you emerge a newer rust{-bin} but you can still have llvm:13 and > lld-13 installed. If you use system-wide gcc, but clang+lto for firefox, > you're not updating lld along with system updates. The only thing stopping on my system LLD being upgraded was Firefox - and now I've rebuilt it manually, LLD gets upgraded. The fact it's BDEPEND only doesn't affect how Portage can see or not see / apply the dependency change / MAX_SLOT change.
(In reply to Sam James from comment #7) > > The fact it's BDEPEND only doesn't affect how Portage can see or not see / > apply the dependency change / MAX_SLOT change. Is that a bug in portage then? Since that should _always_ be queried from the ebuild per PMS, to my understanding.
FWIW... emerge -1av llvm:14 clang:14 =sys-devel/lld-14.0.0 emerge -av firefox:rapid ...did solve my immediate issue. That said, I know the instructions on the ebuild try to be as explicit as possible, but IMO, they could use some improvement.
(In reply to Joonas Niilola from comment #8) > (In reply to Sam James from comment #7) > > > > The fact it's BDEPEND only doesn't affect how Portage can see or not see / > > apply the dependency change / MAX_SLOT change. > > Is that a bug in portage then? Since that should _always_ be queried from > the ebuild per PMS, to my understanding. Once it's installed, there's no obligation for the PM to re-read-and-re-parse dependencies in ebuilds. If it's _not_ yet installed, I think it must re-read. In this case, Firefox is in an installed state and there's no reason for the PM to know that it can update the dependencies stored in vdb, even though it is BDEPEND. BDEPEND isn't treated specially, but the reason we can get away with not revbumping for BDEPEND changes is usually that it wouldn't have built anyway -- but it's totally a hack, and often, we actually _should_ - either to let people depclean a bad dep (more important if it gets rare updates, not so much w/ Firefox), or to prevent them e.g. downgrading a package (again kind of a niche scenario). Best example of when to is something like a < dep.
The exact problem reappeared on 99.0.1... and, it seems like clang, llvm, and friends got updates to 14.0.1, however, they aren't installed. Regardless, 14.0.0 is installed, shouldn't it work?
(In reply to Sam James from comment #10) > Once it's installed, there's no obligation for the PM to > re-read-and-re-parse dependencies in ebuilds. > > If it's _not_ yet installed, I think it must re-read. > Try it out. Install something, add a new DEPEND line without revbumping and re-emerge it. It will pull the new dep.
(In reply to Randall from comment #11) > The exact problem reappeared on 99.0.1... and, it seems like clang, llvm, > and friends got updates to 14.0.1, however, they aren't installed. > Regardless, 14.0.0 is installed, shouldn't it work? Yes it should. You probably have some mismatches due to manual intervetion previously? Or something equally weird.
(In reply to Joonas Niilola from comment #12) > (In reply to Sam James from comment #10) > > Once it's installed, there's no obligation for the PM to > > re-read-and-re-parse dependencies in ebuilds. > > > > If it's _not_ yet installed, I think it must re-read. > > > > Try it out. Install something, add a new DEPEND line without revbumping and > re-emerge it. It will pull the new dep. Re-emerging it isn't the same as it being caught when you do a world upgrade though. If it's already installed, the DEPEND applies and will affect other packages if it's got a <.
(In reply to Sam James from comment #14) > > Re-emerging it isn't the same as it being caught when you do a world upgrade > though. If it's already installed, the DEPEND applies and will affect other > packages if it's got a <. After re-reading this discussion, I came to a conclusion that we're saying the same thing. 1: Yes newly added deps won't get pulled if there's no reason to visit the ebuild, I even said this much (agreed) in #c6. 2: We both suggested re-emerging firefox to fix this (you in #c5, me in #c4). After I suggested to re-emerge firefox manually I guess we got disconnected here, you insisting on #1 and me on #2. But I'd say we both agree here and are just bouncing the ball at this point :) in the end llvm:14 support was added pretty quickly to firefox when it became available to avoid this mess. Anyway based on feedback from #c9 I do plan to improve the error message at some point.
Thank guys. Let me say I've been able to figure out most of the issues, but one...and that problem is sys-devel/lld. Firefox still complains that lld is stuck at 13 because currently, I have LibreOffice (which already has an update in the pipeline to move to 14) and the Intel Graphic Compiler (which doesn't have an update to move to 14 in the pipeline, and is currently not possible because of certain incompatibilities with upstream's dependencies) installed. These two require the LLVM 13 stack to be installed, and because lld is not slotted, only one version of lld is allowed to be installed at a time. Therefore, it would seem that in reality, multiple versions of LLVM/clang CAN NOT be installed simultaneously as long as lld is dictated by the earliest version of LLVM. At least from my observations with Firefox. That said, though, I've been wondering, is there a reason lld is not slotted?
(In reply to Randall from comment #16) > > Firefox still complains that lld is stuck at 13 because currently, I have > LibreOffice (which already has an update in the pipeline to move to 14) and > the Intel Graphic Compiler (which doesn't have an update to move to 14 in > the pipeline, and is currently not possible because of certain > incompatibilities with upstream's dependencies) installed. These two require > the LLVM 13 stack to be installed, and because lld is not slotted, only one > version of lld is allowed to be installed at a time. Yep, can imagine. I have a vague memory of sticking to stable llvm/clang toolchain for this reason on unstable, and using non-bin rust so it's always built with the stable llvm stack. (You can do this with package.accept_keywords -> cat-egory/app -~amd64). These are obviously workarounds, but this is a pretty difficult problem to solve from portage's POV. > > Therefore, it would seem that in reality, multiple versions of LLVM/clang > CAN NOT be installed simultaneously as long as lld is dictated by the > earliest version of LLVM. At least from my observations with Firefox. > > That said, though, I've been wondering, is there a reason lld is not slotted? I know this is a question that arises often, but from a quick search, only found https://bugs.gentoo.org/691900 AFAIK this subject has been raised even in our gentoo-dev mailing list. Don't remember the outcome, but clearly slotted lld wasn't it.
> Yep, can imagine. I have a vague memory of sticking to stable llvm/clang > toolchain for this reason on unstable, and using non-bin rust so it's always > built with the stable llvm stack. (You can do this with > package.accept_keywords -> cat-egory/app -~amd64). > > These are obviously workarounds, but this is a pretty difficult problem to > solve from portage's POV. Fair enough. I think also, virtual/rust recently changed to -bin instead of regular Rust; or maybe at some point I just installed Rust instead of the -bin, I dunno. Regardless, TY for help.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cdea41f06d1c07dc3decf85c878e2a80a4674947 commit cdea41f06d1c07dc3decf85c878e2a80a4674947 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-05-03 17:23:19 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-05-03 17:31:06 +0000 www-client/firefox: add 100.0 - introduce 'system-python' as package.use.masked, which is being worked on, - increase the required non-lto build directory size by 100M, - mask 'sndio' use flag (#842420), - migrate to the new "--enable-audio-backends", - write a better message when rust/llvm/lld mismatches happen. Big 100 🎉 Bug: https://bugs.gentoo.org/838121 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/Manifest | 99 +++ www-client/firefox/firefox-100.0.ebuild | 1259 +++++++++++++++++++++++++++++++ www-client/firefox/metadata.xml | 27 +- 3 files changed, 1372 insertions(+), 13 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e189bd44d4b1cebb8281b646b1452819660b934 commit 6e189bd44d4b1cebb8281b646b1452819660b934 Author: Joonas Niilola <juippis@gentoo.org> AuthorDate: 2022-05-04 05:36:02 +0000 Commit: Joonas Niilola <juippis@gentoo.org> CommitDate: 2022-05-04 05:44:34 +0000 www-client/firefox: enhance the rust/llvm/lld message even further Bug: https://bugs.gentoo.org/838121 Signed-off-by: Joonas Niilola <juippis@gentoo.org> www-client/firefox/firefox-100.0.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
I'm hitting this issue. I have a stable system. Stable rust does not support llvm-14 AFAICT. Therefore I think neither should Firefox and Thunderbird (so I disagree with the CANTFIX). (Stable LibreOffice doesn't support llvm-14 either yet.) Will masking llvm-14 provide a workaround for the issue?
*** Bug 850520 has been marked as a duplicate of this bug. ***
(In reply to Erik Quaeghebeur from comment #21) > I'm hitting this issue. I have a stable system. Stable rust does not support > llvm-14 AFAICT. Therefore I think neither should Firefox and Thunderbird (so > I disagree with the CANTFIX). (Stable LibreOffice doesn't support llvm-14 > either yet.) > > Will masking llvm-14 provide a workaround for the issue? See bug 850202, but yes, it would.
