Set indirect linking for non wasm / RISC-V targets

[luca-della-vedova]

⚠️ This was very AI generated so please take it with a lot of salt, just a bit more than an issue ticket with a copy-pasted error ⚠️

While I was trying to use rules_rs to build a target through a config=remote configuration, (specifically zenoh-c) I bumped into this error:

  (08:38:14) ERROR: /home/runner/.cache/bazel/_bazel_runner/80ee21f5abd5872fd13fbc92e73e36c7/external/rules_rs++rules_rust+rules_rust/util/process_wrapper/BUILD.bazel:4:36: Compiling Rust (without process_wrapper) bin @@rules_rs++rules_rust+rules_rust//util/process_wrapper:process_wrapper (6 files) [for tool] failed: (Exit 1): bootstrap_process_wrapper failed: error executing Rustc command (from target @@rules_rs++rules_rust+rules_rust//util/process_wrapper:process_wrapper) 
    (cd /home/runner/.cache/bazel/_bazel_runner/80ee21f5abd5872fd13fbc92e73e36c7/execroot/_main && \
  error: the self-contained linker was requested, but it wasn't found in the target's sysroot, or in rustc's sysroot

My understanding of the AI investigation

This is quite wildly out of my area of comfort, I tried to feed it into an AI and the recommendation (that works for me) was to make sure to update linker type and rust flags to mirror how linker is set. Specifically, the lines immediately before the diff show that for RISC-V / wasm we use rust-lld (which from what I understand is a "direct" linker since it's embedded in the Rust toolchain), while for other platforms we just use the default that is part of the requested toolchain.
It seems that when no linker is specified (the conditions://default : None branch in the linker's select) Rust falls back to its internal linker, which fails for on Linux / AMD64 with the error above.
This set of changes fixes my build, but I am really out of my depth here.

[dzbarsky]

Thanks for submitting, I'll take a look but might be a week or so until I have cycles!

[luca-della-vedova]

OK after a lot of hand-holding and several tests I reverted everything then created a simple analysis test to act as a regression test (that fails CI) in 1600851, together with a one line fix that makes CI green again in 6120dfc.

Now if I understand correctly the test doesn't actually mean much, I managed to generate a self contained Python test here but, among others, it needs to explicitly ignore the installed toolchain and download llvm to reproduce the issue, which makes it take quite a long time (on my machine a few minutes only to download the toolchain).

Instead, I "vibed" a reproduction example that pulls my branch before / after the fix in https://github.com/luca-della-vedova/self_contained_repro, which is ./repro.sh and ./repro.sh --fix.
Now in this day of payload injections I'd say don't have to run it, but a quick look into .bazelrc, MODULE.bazel can shed some light into when the issue happens, specifically the conditions where this happened for me where:

• A remote execution configuration in CI
• Hermetic action environment
• LLVM on Linux.
• Rust >= 1.90 (so after they switched to lld), which is why I had an intermediate commit of checking on Rust version ac7ec9a

The reproduction itself reliably triggers the issue / fixes the issue.
As mentioned above, changing the toolchain to Rust < 1.90 shows that the issue just doesn't exist, but the build passes either way so it shouldn't (I believe) introduce any regression.
If you are open to a regression test that could take a few minutes because of the LLVM download I can commit it instead of the almost instantaneous static analysis.