Nightly `rustc-dev` can't be used in cross-compilation

[tombh]

Bug

I've made a minimal reproducible repo: https://github.com/tombh/nightly_cross_minimal_repro

Pasting main.rs:

#![feature(rustc_private)]

extern crate rustc_ast;
extern crate rustc_driver;
extern crate rustc_macros;

fn main() {
    println!("{}", rustc_ast::node_id::CRATE_NODE_ID)
}

The build commands are here: https://github.com/tombh/nightly_cross_minimal_repro/blob/main/.github/workflows/ci.yml

Pasting the most relevant part:

rustup toolchain install nightly-2024-09-30
rustup default nightly-2023-09-30
rustup target add aarch64-unknown-linux-gnu
rustup component add rust-src rustc-dev-aarch64-unknown-linux-gnu llvm-tools
...
cargo -v build --locked --release --target aarch64-unknown-linux-gnu

And here is the failing build: https://github.com/tombh/nightly_cross_minimal_repro/actions/runs/11463471346/job/31897390824#step:5:9

Also, just out of interest, here is a failing build with a more recent nightly (nightly-2024-10-21), it fails differently, it can't find derive_where: https://github.com/tombh/nightly_cross_minimal_repro/actions/runs/11463505291/job/31897508604#step:5:9

Relevant Issues

• The bug is being discussed in a rustup issue: "Can't find crate for rustc_*" when cross-compiling a crate with rustc_private on rustup#3255. That is where it was suggested that this is rather a rust or cargo issue.
• build fails with error[E0463]: can't find crate for rustc_macros which rustc depends on in rustc_llvm #62447
• Duplication of libLLVM-*.so in the distributed rustc component. #70838

[jieyouxu]

maybe cc #75247

[bjorn3]

Cross-compilation of tools that link against rustc internal libraries is fundamentally impossible outside of the context of building rustc itself. Rustc uses several proc-macros. Proc-macros need to be compiled for the host rather than the target. It is unreasonable to compile a copy of the proc-macros for each possible system which you want to cross-compile from. Aside from the fact that rustc itself doesn't currently support recording the hashes of all these proc-macro versions in the crate metadata. There is the -Zdual-proc-macro hack to support recording a single pair of host+target for proc-macros, but this doesn't extend to multiple hosts.

[tombh]

Does that mean that it could be possible for rustup to prevent something like: rustup component add rustc-dev-aarch64-unknown-linux-gnu if the current target is not aarch64-unknown-linux-gnu?

Or at least, should this issue be converted to a documentation issue? And/or could the error messages be improved?

[bjorn3]

Yeah, I think it would make sense to omit rustc-dev-aarch64-unknown-linux-gnu from the rustup manifest for hosts other than aarch64-unknown-linux-gnu.

[workingjubilee]

I think?

[tombh]

So would it be useful for me to make an issue on the rustup repo? Something along the lines of, "Omit rustc-dev from manifest on foreign hosts"?

[bjorn3]

The manifest is generated by code in this repo. Rustup only reads the manifest.

[tombh]

Ah right, so the issue here is enough.

I've never looked at the codebase here, so I don't suppose I'd be able to easily help out, though I'm certainly open to the possibility.