configure Rust to use stable channel

[jaluja-doitnow]

(created using eb --new-pr)

[jaluja-doitnow]

TL;DR: This solves an issue, where RPATH would not be set on EasyBuild packages that depend on Rust/Cargo.

When building Rust from source, Rust "auto-detects" the channel that should be used, and defaults to nightly. Since a year ago, nightly Rust builds default to the rust-lld linker (aka LLVM's lld). For more details, please look into: https://blog.rust-lang.org/2024/05/17/enabling-rust-lld-on-linux.html

On RPATH enabled deployments, this creates an issue, as there is currently no RPATH wrapper for lld, so RPATH would not be generated on EasyBuild packages that depend on Rust/Cargo.

Simply setting the channel to stable fixes the issue, as Rust will now use the default linker instead of rust-lld

[boegel]

We took a different approach to fixing the RPATH linking issue in:

• specify path to gcc RPATH wrapper to linker option of Rust compiler #3698

That said, Rust defaulting to "nightly" in any way definitely seems wrong to me...
Does that mean we're not controlling the Rust build fully?

What does the "channel" that's being used imply exactly?

[jaluja-doitnow]

Hello! I see, #3698 is also a good workaround for the RPATH issue.

The nice thing about setting the channel to stable, is that users running cargo/rustc manually (Not necessarily inside EasyBuild) will use the default linker available in their environment, instead of forcing rust-lld by default.

As for how the channel is decided, the default configuration on the Rust sources is:
If tarball source -> auto-detect channel
Else -> dev channel

For auto-detect (Our case, as we are using a source tarball) it just picks the channel set in the src/ci/channel file, as can be seen in: https://github.com/rust-lang/rust/blob/645d0ad2a4f145ae576e442ec5c73c0f8eed829b/bootstrap.example.toml#L650C75-L650C89, which by default is nightly https://github.com/rust-lang/rust/blob/master/src/ci/channel

As for what nightly channel means in Rust. Basically nightly enables some unstable/experimental features, that might be added down the line to the beta channel, and then to the actual stable release of Rust. So nightly is more meant to try out new features that will be added to the next release of Rust, or if you require one of these bleeding-edge features.

Documentation on the Rust Channels: https://rust-lang.github.io/rustup/concepts/channels.html
Rust unstable book, containing all available unstable features: https://doc.rust-lang.org/unstable-book/

[boegel]

@jaluja-doitnow Thanks a lot for clarifying, that's very helpful!

That does mean we're in a bit of a pickle...
While I'm all in favor of making sure that Rust is configured to use the stable channel, it also means that we need to re-test everything that's built on top of those Rust installations, since some Rust crates may actually require some of those nightly features.
A quick count shows that involves 88 easyconfigs. Nothing particular insane, but a significant effort.

And I fully expect that some problems will emerge from testing that change, and fixing those problems will likely require significant effort...

cc @Micket

[boegel]

@boegelbot please test @ jsc-zen3
EB_ARGS="--installpath /tmp/$USER/pr3691-2022a Rust-1.60.0-GCCcore-11.3.0.eb Rust-1.65.0-GCCcore-11.3.0.eb polars-0.15.6-foss-2022a.eb rustworkx-0.12.1-foss-2022a.eb Safetensors-0.3.1-foss-2022a.eb Longshot-0.4.5-GCCcore-11.3.0.eb libavif-0.11.1-GCCcore-11.3.0.eb librsvg-2.55.1-GCCcore-11.3.0.eb maturin-1.3.2-GCCcore-11.3.0-Rust-1.65.0.eb Python-3.10.4-GCCcore-11.3.0.eb tokenizers-0.13.3-GCCcore-11.3.0.eb"
CORE_CNT=16

[boegelbot]

@boegel: Request for testing this PR well received on jsczen3l1.int.jsc-zen3.fz-juelich.de

PR test command 'if [[ develop != 'develop' ]]; then EB_BRANCH=develop ./easybuild_develop.sh 2> /dev/null 1>&2; EB_PREFIX=/home/boegelbot/easybuild/develop source init_env_easybuild_develop.sh; fi; EB_PR=3691 EB_ARGS="--installpath /tmp/$USER/pr3691-2022a Rust-1.60.0-GCCcore-11.3.0.eb Rust-1.65.0-GCCcore-11.3.0.eb polars-0.15.6-foss-2022a.eb rustworkx-0.12.1-foss-2022a.eb Safetensors-0.3.1-foss-2022a.eb Longshot-0.4.5-GCCcore-11.3.0.eb libavif-0.11.1-GCCcore-11.3.0.eb librsvg-2.55.1-GCCcore-11.3.0.eb maturin-1.3.2-GCCcore-11.3.0-Rust-1.65.0.eb Python-3.10.4-GCCcore-11.3.0.eb tokenizers-0.13.3-GCCcore-11.3.0.eb" EB_REPO=easybuild-easyblocks EB_BRANCH=develop /opt/software/slurm/bin/sbatch --job-name test_PR_3691 --ntasks="16" ~/boegelbot/eb_from_pr_upload_jsc-zen3.sh' executed!

• exit code: 0
• output:

Submitted batch job 6448

Test results coming soon (I hope)...

Details

- notification for comment with ID 2903915609 processed

Message to humans: this is just bookkeeping information for me,
it is of no use to you (unless you think I have a bug, which I don't).

[boegelbot]

Test report by @boegelbot

Overview of tested easyconfigs (in order)

• SUCCESS Rust-1.60.0-GCCcore-11.3.0.eb
• SUCCESS Rust-1.65.0-GCCcore-11.3.0.eb
• SUCCESS Longshot-0.4.5-GCCcore-11.3.0.eb
• SUCCESS libavif-0.11.1-GCCcore-11.3.0.eb
• SUCCESS librsvg-2.55.1-GCCcore-11.3.0.eb
• SUCCESS Python-3.10.4-GCCcore-11.3.0.eb
• SUCCESS tokenizers-0.13.3-GCCcore-11.3.0.eb
• FAIL (build issue) polars-0.15.6-foss-2022a.eb (partial log available at https://gist.github.com/boegelbot/d9a89f937c5dd76fef7205cfec905de1)
• SUCCESS rustworkx-0.12.1-foss-2022a.eb
• SUCCESS maturin-1.3.2-GCCcore-11.3.0-Rust-1.65.0.eb
• SUCCESS Safetensors-0.3.1-foss-2022a.eb

Build succeeded for 10 out of 11 (11 easyconfigs in total)
jsczen3c2.int.jsc-zen3.fz-juelich.de - Linux Rocky Linux 9.5, x86_64, AMD EPYC-Milan Processor (zen3), Python 3.9.21
See https://gist.github.com/boegelbot/4d25515e7821b28d09d0fe58757e3495 for a full test report.

[boegel]

The failure with polars-0.15.6-foss-2022a.eb most likely has nothing to do with the switch to the stable channel, but more with the fact that we don't control which (versions of) Rust crates are being used when installing this easyconfig.

A very recent of icu_locale_core is being pulled in, which requires a very recent version of Rust:

error: package `icu_locale_core v2.0.0` cannot be built because it requires rustc 1.82 or newer, while the currently active rustc version is 1.65.0-dev

[boegel]

After extensive testing with reinstalling easyconfigs that include Rust crates on top of Rust installations that were installed with this updated easyblock, I need to conclude that configuring Rust so the stable channel is used doesn't lead to the fallout that I was expecting.

In fact, I haven't seen any easyconfig fail with a problem that could be attributed to this change in the configuration of the Rust installation.

So, I'll go ahead and get this merged. Should there be any fallout in isolated cases, we'll deal with them.