`--sysroot` from rustflags is ignored for proc-macro runtime lib search paths

[weihanglo]

Problem

cargo careful test fails to run unit tests for proc-macro crates since rust-lang/rust@887804d5686
The test executable is compiled successfully,
but the dynamic loader cannot find the libstd built by cargo-careful:

     Running unittests src/lib.rs (target/debug/build/pm-repro/e6767d554e5978c6/out/pm_repro-e6767d554e5978c6)
.../pm_repro-e6767d554e5978c6: error while loading shared libraries: libstd-120c9d4d8f02a466.so: cannot open shared object file: No such file or directory
error: test failed, to rerun pass `--lib`

This is likely due to #17276.

Before that PR,
Cargo probed --print=sysroot as part of the target probe, which passed custom rustflags to the probing invocation:

rustc <rustflags> [--target <target>] --print=sysroot ...

After, it became a plain rustc --print=sysroot

cargo-careful seems to use https://crates.io/crates/rustc_build_sysroot to build a custom std
and invokes Cargo with --sysroot <careful-sysroot>.
The actual test binary is linked against the custom libstd from cargo-careful sysroot, hence the failure.

Steps

cargo install cargo-careful@0.4.10 --locked
rustup component add rust-src --toolchain nightly

cargo new --lib pm-repro
printf '\n[lib]\nproc-macro = true\n' >> pm-repro/Cargo.toml
cd pm-repro && cargo +nightly careful test

Possible Solution(s)

A few options in my mind:

• Revert refactor: move sysroot lookup to GlobalContext #17276

• Respect custom rustflags, though we then need to think about target rustflags and host rustflags interacdtion, which is a bit annoying. Otherwise we couldn't cover below settings.

   [target.aarch64-unknown-linux-gnu]
   rustflags = ["--sysroot", "/opt/sysroots/aarch64"]
   [target.x86_64-unknown-linux-gnu]
   rustflags = ["--sysroot", "/opt/sysroots/x86_64"]

Notes

Original downstream report: RalfJung/cargo-careful#55

Version

GOOD rustc 1.99.0-nightly (7608eb7b0 2026-08-05)
Cargo 7c83d4cc0953b81d823e47d640c64da9b8bd4fac (2026-07-29)

BAD rustc 1.99.0-nightly (84b36a78a 2026-08-06)
Cargo c79e8f89441b3e73d6d65d125c0c745792808c74 (2026-08-04)

[weihanglo]

cc @RalfJung @adamgemmell

[epage]

I think some more fundamental questions are

• do we intend to support custom sysroots? RUSTFLAGS is a "here be dragons" with cases like this
• how does this fit in with build-std?

[weihanglo]

I think some more fundamental questions are

• do we intend to support custom sysroots? RUSTFLAGS is a "here be dragons" with cases like this

Yeah I forgot to put this option in the description.

Also note that there are some rustc-wrappers expecting certain numbers of rustc invocations and they makes assumptions also on custom flags being passed. While this is not a compatible layer Cargo guarantees, we might want to be cautious.

[RalfJung]

Yeah it's entirely possible that cargo-careful just shouldn't do what it is doing. Though I don't know if there is a good alternative, I have not yet spent any time actually trying to get cargo-careful to work again for proc-macros. My current hope is that I can entirely replace cargo-careful by just some -Zbuild-std invocations and hopefully that avoids such problems. I don't really have time to maintain cargo-careful anyway...

But either way I wasn't sure if you were aware of how that PR changed behavior, that's why I pinged you. "This is is the new expected behavior" is a possible answer.

[adamgemmell]

It would be difficult to fully support different sysroots for different targets with build-std (because of the possibility of rust-src differing per target), but I'd like to not regress Cargo's behaviour in this way.

A convenient middle-ground here could be to re-add sysroot to TargetInfo, which respects target-specific rustflags, keeping existing behaviour. Then we'd document the gctx one as being the "global" sysroot without any target-specific configuration (but still respecting RUSTFLAGS). Currently its only user would be build-std, for getting the path to rust-src.

[weihanglo]

We recently had a similar rustflags conflict issue for --verbose and later we reverted it for beta and nightly (see #16531 (comment)). If we want to be extra cautious, I think we can follow the same path: reverting it first to buy us more time for a better mitigation.

OTOH, some naive code search shows me:

• https://github.com/wvhulle/ferrous-owl/blob/e6eb33c891d10f6acc63c2534ab11851ee4a7271/src/toolchain.rs#L84
• https://github.com/heckmon/android-arm64-shared-libraries/blob/4117061fea0db19ce82e817d767ffa98b09cbde8/loader.c#L770
• https://github.com/Joeyh021/pyromaniac/blob/969cdc64028b3e03b999f606d5c5b5d6ce530ad7/pyrod/src/run/rust.rs#L35
• https://github.com/kalebvonburris/Bevy-Asteroids/blob/0098148f1e91f2f52b5dcffb3b4d9c715c0b812e/shell-wasm.nix#L48
• https://github.com/japaric/xargo/blob/68e0ca57cd90837fe02f262f074182f9cfeb6227/src/cargo.rs#L50-L54
• https://github.com/void-linux/void-packages/blob/de737c128ff72db2519fe4cfb44a9250ea550943/common/cross-profiles/ppc.sh#L9
• https://github.com/apache/teaclave-sgx-sdk/blob/f51f56da67fccd919b5dafee9c35d6881a8e15d8/samplecode/cov/Makefile#L104
• https://github.com/CRust-OS/CRust-OS/blob/6cbb111efcc76fb9e3ae2e0b6b01e1353b38c791/build/Rust.mk#L18
• https://github.com/MohammadMuzamil23/Qunix-Operating-System/blob/fe6baf421e12ede976d6d1eaff469f70c972837e/build_kernel.sh#L12
• https://github.com/AOSPA/android_build_soong/blob/f141227991804087d2171aacd8d5ffe769495a9c/rust/builder.go#L371

Looks like most of them could benefit from stabilizing build-std.

[weihanglo]

Though not sure whether most of them will be impacted by this change. Probably not because they are not running proc macro unit tests.

[adamgemmell]

I can do a fix for this since I broke it, but I'm not sure what would be preferable for maintainers. To me the options appear to be:

1. Just add RUSTFLAGS to this new probe and say that per-target sysroots are unsupported. This is very easy.
2. Do my above suggestion which maintains the old target-specific behaviour where possible. It's slightly harder and comes with an ongoing maintenance burden as there's another source of truth for the sysroot.
3. Do nothing, and force users to shim rustc or something if they want to override the sysroot.
4. Revert refactor: move sysroot lookup to GlobalContext #17276 and I'll work out a different solution which will likely involve constructing TargetInfos earlier

Personally my vote is for 1. unless a use case for per-target sysroots appears.

[weihanglo]

Personally my vote is for 1. unless a use case for per-target sysroots appears.

I am okay with this, though we probably need to check with xargo maintainers and users, as they may be likely having some of those use cases.

[RalfJung]

There are no xargo maintainers, it is unmaintained. Though there may still be users...

(Miri and cargo-careful do not use xargo. They use https://github.com/RalfJung/rustc-build-sysroot/ .)

[weihanglo]

@RalfJung is --target <tuple> a valid and recommended use case? I wonder if it won't work with option 1…

(I don't expect you spend time on it btw, as you already said that you have less time to maintain it 🙇🏾‍♂️)

cargo +nightly careful test --target <tuple>

[RalfJung]

Ideally it should behave just like cargo, so yeah that is supposed to work. We also test this a bit (see here).