Remove requirement for --target

[ehuss]

The current implementation requires --target to be specified. Building in "cross compile mode" is required because host dependencies (proc macro especially) must use the sysroot from the compiler.

I don't think this can be changed, but we should infer the --target flag if it is not specified. The problem is that the decision to enable "cross compile mode" is done too early (before it is known that the standard library will be built). We'll need to figure out some way to work around this.

The crux of the issue is that BuildConfig::requested_target needs to be set, but BuildConfig is constructed extremely early. Decisions like this will need to know if the standard library is being built.

I'm not sure how to deal with this.

[Ericson2314]

Building in "cross compile mode" is required because host dependencies (proc macro especially) must use the sysroot from the compiler.

I don't think this can be changed

We should check with the compiler team what exactly the bootstrapping requirements are. For example, ideally Rust can be bootstrapped from a plain compiler with no prebuilt libraries if one has the source for the bootstrapping compiler.

CC #19

[alexcrichton]

I'm less certain that we'll be able to do this in the long term myself. Morally you're right in that we can auto-switch to "as if --target was passed" but that also changes the output structure. It'd be somewhat surprising if cargo build generated target/debug/foo and cargo build -Z build-std generated target/$host/debug/foo. Or at least that's just to say that this may not be quite as simple as just switching to "as if we passed --target" mode early in Cargo if we want to preserve the same output structure.

If we preserve the same output structure (as if --target was passed and if it weren't) then I think this'd work great! (this seems totally fine to worry about after an initial pass of stabilization though)

---

@Ericson2314 the requirement that proc-macros and build scripts use the host compiler's sysroot isn't going to change any time soon. That should be in a dedicated separate issue if you'd like to see that pursued.

[Ericson2314]

#42 opened

[jyn514]

The current implementation requires --target to be specified. Building in "cross compile mode" is required because host dependencies (proc macro especially) must use the sysroot from the compiler.

Can you talk more about this? Why must host dependencies use the sysroot?

My understanding of this is something like "in cross-compile mode, RUSTFLAGS is not passed to build scripts, but in host mode it is", but I'm not sure why that's related to the sysroot?

[ehuss]

I don't remember the reasoning.

Perhaps there were issues with dylib loading or ABI compatibility (particularly in the face of any RUSTFLAGS)?

One possibility was to avoid building the standard library twice when cross-compiling.

Another possibility is that this was an issue when cargo used --sysroot instead of --extern?

It may be possible to remove this requirement if we're willing to take the hit of building it twice, and we can convince ourselves that the proc-macro crate doesn't have any weird ABI issues. I think with global caching, that might not be as bad.

[harmou01]

Has there been any update on this since May 2023? I've been looking into it, and so far haven't found any issues with removing this requirement.

I've tried playing around with proc_macro's, build scripts and some RUSTFLAGS, but things seem to build fine. Any ideas of anything else to look at?

[harmou01]

Some additional info: I've been looking into this issue. I have removed the requirement for --target in build_config.rs, so by default Cargo will use the Host CompileKind, rather than a CompileTarget.

Having tested a few things to see if this causes issues, such as using proc_macros (both in the crate, and the build script), as well as passing some RUSTFLAGS:

• -Zsanitizer=cfi - the only issue this causes is building on aarch64-apple-darwin, where i get numerous linker issues for unknown options -plugin-opt=O0 -plugin-opt=mcpu=apple-m1. Building on a Linux/x86 machine is fine.
• -Cembed-bitcode=yes -Cforce-frame-pointers=yes -Cforce-unwind-tables=yes -Crelocation-model=pie -Csoft-float=yes -Zbranch-protection=pac-ret are some of the flags i tried that i thought might cause issues, but was fine.

I'm unable to observe any issues when building. If there are any particular edge cases that i may have missed, please let me know. Additionally, I haven't observed std being built twice with this change (running cargo with --verbose).

[harmou01]

As the PR has been merged, we can close this issue now? @ehuss

[ehuss]

Indeed, thanks!