Figure out how to handle target-specific settings.

[ehuss]

Some targets are not supported because they have special logic in bootstrap for flags/features needed. musl, wasi, windows-gnu, etc. Will need to figure out how to handle these. It would be ideal not to hard-code them in cargo, but is there some way to specify what's needed via config files?

Here are some examples:

• https://github.com/rust-lang/rust/blob/266fa0c26acb7de34654908f86eab0a77c9c9571/src/bootstrap/compile.rs#L325-L360
• https://github.com/rust-lang/rust/blob/266fa0c26acb7de34654908f86eab0a77c9c9571/src/bootstrap/compile.rs#L115-L152
• https://github.com/rust-lang/rust/blob/266fa0c26acb7de34654908f86eab0a77c9c9571/src/bootstrap/bin/rustc.rs#L164-L179

[alexcrichton]

To give some background on these examples and why they exist in rustbuild:

• https://github.com/rust-lang/rust/blob/266fa0c26acb7de34654908f86eab0a77c9c9571/src/bootstrap/compile.rs#L325-L360

  This is specific to MinGW and is part of our desire to not require a C compiler be installed for usage of the MinGW toolchain. This means that the C compiler we ship (yes, we ship gcc.exe for MinGW) needs to be able to find all the assorted things for linking, and this is what we're passing. A few of the object files here are compiled from Rust. Additionally we literally copy in some C objects from the C compiler we're building the whole toolchain with.

  The Rust-specific object files are unfortunate because they have no equivalent anywhere else. Additionally they're very specific to MinGW so it's not like they fit in a general framework. These object files are encoded into the target specification and is where they end up getting passed to the linker.

  I think we could probably survive quite some time by just saying -Z build-std doesn't support MinGW.

• https://github.com/rust-lang/rust/blob/266fa0c26acb7de34654908f86eab0a77c9c9571/src/bootstrap/compile.rs#L115-L152

  I can't speak as to what's going on with sgx here, but wasi/musl both serve the same purpose. We want to build a distribution, like with MinGW above, which doesn't require a C compiler when you compile for the target. (or at least not a full C compiler). For wasi this means that we also ship rust-lld, and for musl it means that we work with plain old gcc since we're just using that as a linker.

  Like with MinGW these files are encoded in target specs (here's musl and here's wasi). These object files all sort of have "well known" definitions, but there's not really any way to generate them from source.

  We're probably mostly out of luck dealing with these objects.

• https://github.com/rust-lang/rust/blob/266fa0c26acb7de34654908f86eab0a77c9c9571/src/bootstrap/bin/rustc.rs#L164-L179

  These statements are borne out of the desire to, again like above, not require a full toolchain when compiling locally with the target. These statements here basically say "here's where libc.a is located" and then that libc.a is slurped up into liblibc.rlib which we then ship to users.

  From a build-std perspective there's not a huge amount we can do...

I think that roughly everything fits in this bucket of "weird toolchain muck", and I can't really think of a better solution other than the following. We could update the source code in rust-lang/rust to know when it's being built by Cargo, and in that case it tweaks how linkage works. The base assumption is that you, the builder, have a full development toolchain for the target locally that rustc can use. The linker itself would pull in the right object files from itself (rustc wouldn't tell the linker to stop injecting object files) and crates like liblibc when linked by libstd would unconditionally say -lc to pull in the system C library.

All-in-all I think that for stabilization we probably want to be conservative and either have a whitelist or a blacklist of targets. This problem generally affects anything requiring a C library (since it's loaded from the system), and only targets that have zero non-Rust dependencies (wasm32-unknown-unknown, custom target specs, etc) are guaranteed to work.

[Ericson2314]

Distros and extern build systems using Cargo would want to handle these special cases themselves anyways. It's just easier for them if Cargo doesn't special case those platforms.