Bootstrapping logic has trouble with target triples with dots in the name (e.g. `thumbv8m.main-none-eabihf`)

[alex-pinkus]

When running configure to cross-compile for a Cortex M target, a few issues arise with the fact that the target has a . in the name. There are two issues that I noticed:

1. configure.py generates an invalid config.toml — this is easy to fix with a change to the example file.
2. cc_detect.rs looks for compiler flags in difficult-to-name variables — this is harder to fix, but can be (painfully) worked around.

To illustrate issue 1, I tried this code:

git clone https://github.com/rust-lang/rust.git
cd rust
./configure --target "thumbv8m.main-none-eabihf"
python ./x.py dist

I expected to see this happen: compilation should get pretty far (I'm eliding some of the things that would make it actually succeed, for brevity, but successfully building stage0 rustc is expected at least)

Instead, this happened: compilation fails after one minute with the error:

failed to parse TOML configuration 'config.toml': unknown field `main-none-eabihf`, expected one of `cc`, `cxx`, `ar`, `ranlib`, `default-linker`, `linker`, `llvm-config`, `llvm-filecheck`, `android-ndk`, `sanitizers`, `profiler`, `crt-static`, `musl-root`, `musl-libdir`, `wasi-root`, `qemu-rootfs`, `no-std` for key `target.thumbv8m`

This is because the generated config.toml contains this line (note the problematic period):

[target.thumbv8m.main-none-eabihf]

I believe this comes from here, where we unconditionally replace x86_64-unknown-linux-gnu in the example config.toml. If config.toml.example is updated to put quotes around its target architecture, this issue is solved:

[target.'x86_64-unknown-linux-gnu']

Issue 2 takes more effort to reproduce, and is technically not a bug in rustc, but in the cc crate. Or maybe it's not a bug at all, but it's pretty darn unfortunate. In particular, the intended way to specify CFLAGS (and friends) for thumbv8m.main-none-eabihf is to write to the environment variable CFLAGS_thumbv8m.main-none-eabihf, or a few other permutations. The problem: most shells do not allow users to export environment variables that contain the . character:

# bash
$ export CFLAGS_thumbv8m.main-none-eabi="foo"
-bash: export: `CFLAGS_thumbv8m.main-none-eabi=foo': not a valid identifier
# zsh
% export CFLAGS_thumbv8m.main-none-eabi="foo"
export: not valid in this context: CFLAGS_thumbv8m.main-none-eabi

If I fix issue 1 as described above, and use the workaround described here to get around issue 2, I am able to build a target that has a period in it.

Meta

This was tested with current top of tree (commit 9257f5aad02b65665a6e23e5b92938548302e129) but does not appear to be a recent regression.

I see the same behavior when my host is either x86_64-apple-darwin or x86_64-unknown-linux-gnu, which is unsurprising.

I think it makes sense to split issues 1 and 2 into separate bug reports (issue 2 being reported on the cc crate) -- but wanted to get this out there first to simply reflect that targets with dots are currently difficult to build for.

[jyn514]

Thanks for the bug report! I think it's unlikely we will do anything about 2 in rust-lang/rust itself (having a target with a dot and having to set CFLAGS seems rare), but 1 is definitely a bug we should fix.

Mentoring instructions: in

rust/src/bootstrap/configure.py

Line 410 in e52e711

targets[target][0] = targets[target][0].replace("x86_64-unknown-linux-gnu", target)

add quotes around the target we're replacing the default with.

@rustbot label +A-rustbuild +E-easy +E-mentor +E-help-wanted

[yue4u]

@rustbot claim