[SOLVED] Failed to emerge mail-client/thunderbird-68.10.0

[egrep]

Hello,

While emerging Thunderbird I get compilation errors. Below are the steps I took:

[Whissi]

PM will downgrade rust because of https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f5cb899dbdec54bff414db104ce7507cecd6bdcb which also applies to thunderbird-68.10.

Please show full build.log so we don't need to speculate because the quoted error message is not the real error which triggered the build failure.

Best guess: You now have multiple rust implementations installed but still trying to merge thunderbird with rust-1.45 which doesn't work.
_________________
Regards,
Whissi

[egrep]

Here are build logs (16 MB) https://u.pcloud.link/publink/show?code=XZV1NNkZo7SJDxjR9X4PyePF2jpb5f67yixX

[Whissi]

[Hu]

Shouldn't the Thunderbird build automatically use the Rust version it needs, since that version is installed?

[egrep]

I just downgraded rust by masked it in /etc/portage/package.mask:

[Whissi]

[Hu]

That commit appears to be just the dependency data to ensure that a capable version is installed, not that it is used. I know a few ebuilds have tests for specific gcc versions, but I thought it was generally the case that

• the ebuild would warn if the active compiler version was wrong
• requiring specific versions was considered a bug, to be fixed by patching the source to work with all the supported versions of the compiler

I don't see in that ebuild any messaging to the user to warn about incorrect Rust versions, and the experience here suggests the ebuild doesn't apply any necessary patches either. I take it from your last comment that it's not even possible to check the Rust version from an ebuild. Is that right?

Am I wrong, and it is not policy to treat such overly strict requirements as a bug?

This general flow seems like a way to make the Rust experience even more miserable than it already is (and thanks to some bad decisions by upstream, it's already pretty miserable).

[Whissi]

[Ionen]

@Whissi

That solution has a problem, if rust isn't installed "yet" (as in, it's about to be installed alongside thunderbird/firefox), eselect --brief rust show will fail as it is run early in pretend phase, and then lead to this thread. And I don't think there's a sane way to tell which version is about to be installed from pretend.

[Hu]

Perhaps I am being naive, but why not just explicitly run the right version of Rust, instead of insisting that the user update the bare name rust to be a compatible version? Then the detection of exactly what version is available to run could be deferred to src_prepare, which would set a shell variable to the qualified path of a compatible Rust, which would be installed by that point, even if it was not available during pkg_pretend. Does the build system have hardcoded calls to the bare name rust, with no ready way to tell it that it should use some other name? That seems like a serious upstream defect if it can't be given a name/path to use. We have had CC / CXX for the C/C++ compiler name for far longer than Rust has existed, so it seems really weird to me that there would not be a RUSTC or RUSTCC or such variable to specify the desired name (with optional version).

[Ionen]

This starts to be a lot of things for an ebuild to do (check min max version, sanity checks, set variables for likely multiple parts of the toolchain, etc...) and better belong in an eclass. Also ebuilds I seen that need specific versions of gcc (like gcc8-only) seem to tell users to use gcc-config as well.

In this case, it may be simpler to just add the rust 1.45.0 fix rather than limit versions unless there's more problems that I don't know of (it looked rather simple on firefox 78's ebuild, "thought" didn't bother for 68 given 78 is the next ESR and rust 1.45.0 isn't stable anyway. Not famliar with thunderbird's situation though).
Edit: well, looks like there is indeed more to it, ah well

[Whissi]

Hrm. https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1632545a561002c8d2b743f6130bbd25b5a7a742 is all we can do here.

Switching rust implementation on our own in ebuild is not allowed.
_________________
Regards,
Whissi

[Hu]

I am not suggesting that the ebuild use eselect to change the system Rust compiler version. I am suggesting that the ebuild export RUSTC=/usr/bin/rust-1.44 (or such other version as the user has and can use), and that the upstream build system recognize this variable and react by using that path instead of the bare name rust. I say this expecting that, as I noted above, the upstream build system should understand this, since the tradition of having a well-known variable that points to the compiler predates the existence of rust.

As an alternative that is ugly, but might work: dynamically write a trivial shell script, named rust, placed in $PATH ahead of the system paths. This script would have a body such as:

[lefsha]

PLEASE! DO NOT DOWNGRADE RUST.

RUST 1.45 works well. Both Thunderbird and Firefox can be compiled with that. Both work afterwards.

The only change one need to perform is add

RUSTFLAGS="-C embed-bitcode" to /etc/portage/make.conf


Please mark the thread as solved as long portage will be updated. Thx
_________________
Lefsha

[egrep]

As I can see this is fixed in thunderbird-68.11.0.ebuild:

https://gitweb.gentoo.org/repo/gentoo.git/commit/mail-client/thunderbird/thunderbird-68.11.0.ebuild?id=dc49a022d556049fe511b65256f7afa79ca4f7bb