Warning
Info
At risk of describing a niche unsupported workflow (xkcd: Workflow)...
TL;DR
The rustup file for ld.lld on linux seems to reference an absolute path to ~/.rustup which causes problems when ~/.rustup is mounted to a different path (read-only, for a different user).
Why is the "path of the current file" needed in the ld.lld script that rustup creates?
Additional background:
I've had success so far using rustup inside in a container on my NixOS linux machine by mounting my main user's /home/main/.rustup folder as readonly inside the container as /home/unprivileged/.rustup.
After updating my toolchain from ~1.89 to rustc 1.91.0-beta.1 (1bffa2300 2025-09-15), I started having an issue where the unprivileged user's compiles fail, trying to access a path inside /home/main/.rustup.
From my initial look, it seems like this might not be the fault of cursed NixOS shenanigans, or even the read-only mount, but rather because the path /home/main/.rustup is hard-coded inside the rustup folder that isn't valid inside the VM.
The cc linker, when invoked using the /home/unprivileged/.rustup read-only install, is trying to access a script in /home/main/.rustup
Looking into the file, it contains a line defining PROG with the path to the current file.
Contents of /home/main/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld/ld.lld:
#!/usr/bin/env bash
set -eu -o pipefail +o posix
shopt -s nullglob
export PROG="/home/main/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld-unwrapped/ld.lld"
"/nix/store/pwrvyffzg8hzvi4d864q8bmjr7vfaxqz-rustup-1.27.1/nix-support/ld-wrapper.sh" $@
That's a lot of background... my actual question:
Do you know why this file has to record a path to itself?
I don't know much about linkers (seems the default recently changed to lld on x86_64 linux?), but some searching showed that lld is better than the older default?
As a workaround, it works if I mount /home/main/.rustup read-only inside the container too, so that /home/unprivileged/.rustup/ tools can access those hard-coded paths at /home/main/.rustup (with just a small amount of extra read-only clutter).
I thought about changing this file to use /home/${USER}/.rustup instead, but it seems odd to modify a file that rustup will overwrite on the next update.
1 post - 1 participant
🏷️ Rust_feed