Rust 1.45 is not allowed to build both Firefox and Thunderbird, although it works well and has NO issues. Please remove the dependency "<dev-lang/rust-1.45" from both ebuilds. Instead make a news or a note to user to add new variable into /etc/portage/make.conf RUSTFLAGS="-C embed-bitcode" or put the same into ebuilds. Rust in 1.45 has changes its default behaviour where from now on "-C embed-bitcode=no" is applied. Rust 1.44 and earlier worked by default with "-C embed-bitcode=yes" It seems like both Firefox and Thunderbird builds rely on that behaviour. Changing the default settings back like it was at 1.44 helps to build those rust related packages. Please, confirm and revert changes. There is NO single reason why Gentoo should imply rust downgrade or multiple versions of thereof. Thx. P.S. Rust 1.45 is PERFECT. Reproducible: Always Actual Results: Pushing rust 1.44
I have no comment as to the validity or otherwise of the OP's comments but, for anybody reading this bug, they would appear to relate only to the firefox-68* series (i.e. not the current 78.0.2 release - which is admittedly ~arch, atm). I was confused, initially...
You solution is a hack and therefore nothing we can recommend users to do: If user will set this in make.conf, they will build everything with bitcode-enabled (comparable like forcing LTO builds for everything). For example, upstream noticed a regression in build time due to their change by ~10% which they don't accept (bmo#1654465). Also note that "-C embed-bitcode=*" is only supported in >=rust-1.45 which is new and not stable.
(In reply to Thomas Deutschmann from comment #2) > You solution is a hack and therefore nothing we can recommend users to do: > If user will set this in make.conf, they will build everything with > bitcode-enabled (comparable like forcing LTO builds for everything). For Next time before writing such a comment PLEASE - RTFM!!! I remind you. Effectively Rust 1.44 imply embed-bitcode=YES And that was the change introduced in Rust 1.45 where the default behaviour has been altered towards embed-bitcode=NO and that is why the option has been introduced in the first place. Therefore building firefox or thunerbird with Rust 1.44 is the same thing like building it with Rust 1.45 and option embed-bitcode turned to YES. You should not insist user use that option for everything, because it won't be regarded outside the portage tree. People use Rust mostly not with portage. Anything what concerns the portage either pushing Rust 1.44 or use that option is the same! You still don't like it - fine. Modify corresponding ebuilds in case user uses Rust 1.45 add that option. > Also note that "-C embed-bitcode=*" is only supported in >=rust-1.45 which > is new and not stable. I repeat it once again. RTFM!
Please give me back the freedom of choice. There is no objective reasons to insist people use the certain version of Rust. Let people do what they want! It is also not forbidden to use older Rust version. No one is pushed to use the latest one. But ebuild should not break, because I am using the version you personally don't like. You are free to produce a warning or make a proper ebuild, depending on qualification. What is the point of using Gentoo if one will be pushed do something other people decide for them? The freedom of choice must be hardcoded into Gentoo brain! It should be its policy.
Just one more thing. Rust is developing by Mozilla. Firefox is developing by... Mozilla. And some one here is trying to convince me, that they produce a language which is not working for the software it has been written in the first place? It's like saying VC or MS Office is not compatible with Windows... Sounds like a joke.
(In reply to Thomas Deutschmann from comment #2) > Also note that "-C embed-bitcode=*" is only supported in >=rust-1.45 which > is new and not stable. Can't we just selectively edit config/makefiles/rust.mk if the system rust version is >=1.45? If I understand the fix, we just need to append cargo_rustc_flags += -C embed-bitcode=YES for now :P I'm getting some weird rust downgrade shuffle that is bugging me, don't want rust-bin so that is masked and I downgrade to 1.44.1 and then portage is complaining it wants 1.43.1 now ...
(In reply to Michael Cook from comment #6) > Can't we just selectively edit config/makefiles/rust.mk if the system rust > version is >=1.45? If I understand the fix, we just need to append > cargo_rustc_flags += -C embed-bitcode=YES for now :P Well, that's the wrong place to do it, need to experiment more since I'm not that familiar with the mozilla build process.
Why exactly adding RUSTFLAGS variable into make.conf I suggested and implemented on my system is wrong, although it will change the behaviour of Rust in any further version, but downgrade to 1.44 is correct? Every few months newer Rust version will be released for sure. No one will revert the change which has been introduced in 1.45, because what they made is correct and sane. Keeping 1.44 for years is not the option at all. If the certain package cannot be compiled by gcc with -O3 successfully we replace it with -O2 instead of downgrading gcc. Why the same cannot be done here? When Rust will reach 2.55 version would we still insist using 1.44?
`-C embed-bitcode=yes` is only needed for USE=lto builds, and the embed-bitcode flag appeared will error out in versions of rustc before 1.45. https://github.com/rust-lang/rust/issues/71848/ https://bugzilla.mozilla.org/show_bug.cgi?id=1640982 Upstream Firefox has already fixed its build, but it looks like firefox-68 won't be fixed. Didn't check Thunderbird but I expect it's the same. I'd be happy with waiting for upstream's fixed releases and keep the block in place for older thunderbird/firefox versions. But it would indeed be ice if Gentoo carried the patch in the meantime.
firefox-68.11.0 and thunderbird-68.11.0 should now work with >=rust-1.45.0.
Quite funny and common thing about Gentoo. A stable package is not even able to be build, while unstable works... What exactly prevents creation of stable thunderbird-68.10.0-r1 or marking 68.11 as stable? Last 20 years I am not able to understand the logic why some packages called stable and other unstable. Where those few people obtain that secret knowledge? Sounds more like a "head and tails" game.
If you haven't noticed, there is an ongoing stabilization for new firefox in bug 734324. So no need to force people to rebuild an old version with the fix.
