Windows GNU target: rsbegin.o / rsend.o injection is unconfigurable and breaks cross-compilation

[tahadostifam]

What Happend?

When cross-compiling for x86_64-pc-windows-gnu on NixOS (or similar Linux environments), the Rust compiler automatically injects rsbegin.o and rsend.o into the linker command. However, there is no mechanism to configure or override the path to these startup object files.

Linker cannot find the object files unless they are in the expected sysroot location, e.g.:

$HOME/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-pc-windows-gnu/lib

Attempts to pass rsbegin.o / rsend.o manually via RUSTFLAGS or -C link-args result in duplicate object name errors, because the compiler still injects its own copies automatically.

This makes cross-compiling a minimal hello-world executable for x86_64-pc-windows-gnu unreliable on NixOS or other Linux systems using non-standard sysroot paths.

Steps to reproduce:

rustup target add x86_64-pc-windows-gnu
cargo new hello
cd hello
cargo build --target x86_64-pc-windows-gnu -Zbuild-std

Relevant code:

Rust bootstrap currently injects startup objects here:

https://github.com/rust-lang/rust/blob/master/src/bootstrap/src/core/build_steps/compile.rs#L909

for file in &["rsbegin", "rsend"] {
    let src_file = &src_dir.join(file.to_string() + ".rs");
    let dst_file = &dst_dir.join(file.to_string() + ".o");
    if !up_to_date(src_file, dst_file) {
        let mut cmd = Command::new(&builder.initial_rustc);
        cmd.env("RUSTC_BOOTSTRAP", "1");
        ...
        builder.run(
            cmd.arg("--target")
                .arg(target.rustc_target_arg())
                .arg("--emit=obj")
                .arg("-o")
                .arg(dst_file)
                .arg(src_file),
        );
    }
}

Proposed improvement / feature request:

• Allow overriding the path to rsbegin.o / rsend.o via environment variable or Cargo configuration.

• Alternatively, provide a mechanism to disable automatic injection for advanced cross-compilation setups.

This would make cross-compilation on non-standard systems (NixOS, custom sysroots) feasible without hacks.

Environment:

Rust nightly (toolchain: nightly-x86_64-unknown-linux-gnu)
Target: x86_64-pc-windows-gnu
OS: NixOS / Linux
cargo and rustc via rustup

[RossSmyth]

Hello.
I use NixOS nearly everyday to cross-compile Rust software from NixOS to MingwW64, and am also one of the maintainers of Nixpkgs's Windows cross-compilation machinery.

Does this only occur when you use Rustup?

[RossSmyth]

Ok I see, so this happens when you build core. Let me see if I can make a reproducer.

[tahadostifam]

Thanks for responding! =)
But things have escalated a bit. I used cargo-zigbuild to cross-compile my own compiler, @cyrus-lang, and now I’m stuck dealing with its problems too:

I hope Rust’s cross-compilation improves in the future.

[RossSmyth]

If you do not build-std, it should work fine fwiw

[RossSmyth]

Also if you could post your log output that would be great.

[RossSmyth]

So the way that rustc determines where the sysroot is here:

rust/compiler/rustc_session/src/filesearch.rs

Line 186 in 0c0c58b

pub(crate) fn default_sysroot() -> PathBuf {

Basically it finds the path of librustc.so and looks around there. On my computer it is:
/nix/store/lami1gbfhz609fd6d8pi91sxppvyvq8r-rustc-1.89.0/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_driver-e1aea304e70c86e6.so
This is without Rustup, and is just the Nixpkgs-provided rustc.

It then attempts to build libstd and finds /nix/store/lami1gbfhz609fd6d8pi91sxppvyvq8r-rustc-1.89.0/lib/rustlib/src/rust/library/Cargo.lock does not exist, because currently Nixpkgs prunes the rust source to keep the closure size down, as Nixpkgs only distributes stable compilers.

Another way is with https://github.com/oxalica/rust-overlay. This project is what I personally would recommend when using Rust on NixOS, and it seems to get a bit further if you include the "rust-src" extension. For me it just fails at the "download stuff' stage because I am just doing this in the Nix sandbox.

I'm unsure if this is NixOS-related though so far.

[mati865]

Alternatively, provide a mechanism to disable automatic injection for advanced cross-compilation setups.

You cannot disable it for i686 without breaking the unwinding. For x86_64, it's not necessary; it was probably kept for simplicity.

If you do not build-std, it should work fine fwiw

Correct, build-std doesn't support target object files yet: rust-lang/wg-cargo-std-aware#46