bootstrap cannot check library/std for windows from macOS (and possibly others)

[thomcc]

I often write patches for std::sys::windows while not using windows. It would be nice if ./x.py check --target x86_64-pc-windows-msvc library/std worked, but instead it does not -- I get an error like https://gist.github.com/thomcc/7c889b3a1306922f7eda28f45f1d304e (this is from a build where aarch64-apple-darwin is the host).

As a result, to check changes to std::sys::windows while not on windows, I'm forced to a full stage1 build, and then in some other workspace run cargo +stage1 check -Zbuild-std --target x86_64-pc-windows-msvc (where +stage1 is a linked toolchain). This works, but is tedious/time-consuming.

CC @jyn514 who suggested I file this issue, and suggested that it "looks like we're handling the linker arguments wrong when cross compiling".

[jyn514]

@thomcc how did you get that far in the build? When I try it I get

; ./x.py check --target x86_64-pc-windows-msvc library/std
thread 'main' panicked at '
cmake does not support Visual Studio generators.

This is likely due to it being an msys/cygwin build of cmake,
rather than the required windows version, built using MinGW
or Visual Studio.

If you are building under msys2 try installing the mingw-w64-x86_64-cmake
package instead of cmake:

$ pacman -R cmake && pacman -S mingw-w64-x86_64-cmake
', sanity.rs:221:17

[jyn514]

download-ci-llvm worked`

[jyn514]

To reproduce this I also needed to have the llvm submodule checked out so

rust/src/bootstrap/compile.rs

Line 319 in ed37111

cargo.env("RUST_COMPILER_RT_ROOT", &compiler_builtins_root);

would trigger.

[mati865]

You can simply run ./x.py check --target x86_64-pc-windows-gnu library/std once you install mingw-w64 cross toolchain that is usually available for your OS.

Details

Checking stage0 library artifacts (x86_64-unknown-linux-gnu -> x86_64-pc-windows-gnu)
    Updating crates.io index
  Downloaded compiler_builtins v0.1.85
  Downloaded libc v0.2.138
  Downloaded 2 crates (776.6 KB) in 1.23s
   Compiling cc v1.0.76
    Checking core v0.0.0 (/home/mateusz/Projects/rust/library/core)
   Compiling libc v0.2.138
   Compiling memchr v2.5.0
   Compiling std v0.0.0 (/home/mateusz/Projects/rust/library/std)
   Compiling compiler_builtins v0.1.85
   Compiling unwind v0.0.0 (/home/mateusz/Projects/rust/library/unwind)
    Checking rustc-std-workspace-core v1.99.0 (/home/mateusz/Projects/rust/library/rustc-std-workspace-core)
    Checking alloc v0.0.0 (/home/mateusz/Projects/rust/library/alloc)
    Checking cfg-if v1.0.0
    Checking adler v1.0.2
    Checking rustc-demangle v0.1.21
    Checking rustc-std-workspace-alloc v1.99.0 (/home/mateusz/Projects/rust/library/rustc-std-workspace-alloc)
    Checking panic_abort v0.0.0 (/home/mateusz/Projects/rust/library/panic_abort)
    Checking panic_unwind v0.0.0 (/home/mateusz/Projects/rust/library/panic_unwind)
    Checking gimli v0.26.2
    Checking object v0.29.0
    Checking std_detect v0.1.5 (/home/mateusz/Projects/rust/library/stdarch/crates/std_detect)
    Checking miniz_oxide v0.5.3
    Checking hashbrown v0.12.3
    Checking addr2line v0.17.0
    Checking rustc-std-workspace-std v1.99.0 (/home/mateusz/Projects/rust/library/rustc-std-workspace-std)
    Checking proc_macro v0.0.0 (/home/mateusz/Projects/rust/library/proc_macro)
    Checking unicode-width v0.1.10
    Checking getopts v0.2.21
    Checking test v0.0.0 (/home/mateusz/Projects/rust/library/test)
    Finished release [optimized] target(s) in 1m 04s
Checking stage0 library test/bench/example targets (x86_64-unknown-linux-gnu -> x86_64-pc-windows-gnu)
    Checking rand_core v0.6.4
    Checking proc_macro v0.0.0 (/home/mateusz/Projects/rust/library/proc_macro)
    Checking test v0.0.0 (/home/mateusz/Projects/rust/library/test)
    Checking rand v0.8.5
    Checking rand_xorshift v0.3.0
    Checking std v0.0.0 (/home/mateusz/Projects/rust/library/std)
    Checking core v0.0.0 (/home/mateusz/Projects/rust/library/core)
    Checking alloc v0.0.0 (/home/mateusz/Projects/rust/library/alloc)
    Finished release [optimized] target(s) in 8.29s
Build completed successfully in 0:01:45

[thomcc]

That shouldn't be needed to check (it's not needed for check on other targets), and I had trouble getting that to work on aarch64-apple-darwin last time I tried (admittedly it was a while ago, and the situation may have improved).

[jyn514]

Note also that the original issue was for -msvc, not -gnu.

[mati865]

Note also that the original issue was for -msvc, not -gnu.

To me it sounds like this issue is for an ability to generally check sys::windows code without having to use Windows.
I don't deny the fact check should work without the linker (because it should) but this is workaround that allows to check majority of that code on other platforms.

[jyn514]

don't know when I'll have time to follow up on this. here's a summary of the situation:

the original problem was "bootstrap decides to use the optimized-builtins cargo feature depending on whether src/llvm-project is checked out or not". that's silly and confusing so I turned it into a config flag that's off by default locally and on in CI: #101833. that broke a bunch of distros for reasons I don't quite understand - apparently our atomics are broken on some platforms unless we use llvm intrinsics (??? #101833 (comment)) so @pietroalbini reverted that PR. also @tmandry is doing things I don't understand where llvm is out of tree but still rust-lang/llvm-project, and wants bootstrap to behave differently in those cases: #102560

I opened #102579 to try and fix all those three things, but it's currently stuck on whether the default should be optimized-builtins = false or true. the errors for both suck: here's false https://gist.github.com/pietroalbini/33e1a25fecaddc8ad936eb2ba26ecf05
and true: https://gist.github.com/thomcc/7c889b3a1306922f7eda28f45f1d304e

@thomcc says he's seen the error message for true before and fixed it with -Ctarget-feature=-outline-atomics; maybe that would help here?

[jyn514]

@thomcc says we can't turn off outline-atomics because it's part of the target spec and affects ABI, but we might be able to move the outlined atomics from assembly into global_asm so they work properly with cargo check without needing a linker for the target platform installed.

[thomcc]

It doesn't effect ABI (these aren't __sync builtins), the issues are that:

1. These are turned on by either rustc_target and LLVM by somewhat convoluted¹ logic that seems hard for bootstrap to replicate

2. Even if you disable the compiler-builtins C shims, and build the stdlib with RUSTFLAGS=-Ctarget-feature=-outline-atomics, building user code will fail, as the target definition will have re-enabled this as soon as that flag is not provided (but now we won't have definitions for the outline-atomic functions)

So, maybe we should port them to compiler-builtins with global_asm!?

Well, it's unclear. We could port part of it (the function definitions), but part of it depends on being able to perform runtime CPU feature detection, which requires libc on aarch64 Linux targets (specifically the C stub compiled here is responsible for that), and I'm not sure how we want to handle that.

In theory we could compile in a global_asm!-using impl that doesn't ever use runtime feature detection, but this defeats the entire point of outline-atomics, and it's probably better to just find a way to disable the feature globally if built against a compiler-builtins that doesn't have it (somehow?).

IDK, IMO it's kinda a bad situation that we let a mandatory libc dependency slip in on these targets, but I suppose that's just how it is.

Footnotes

1. Grep for IsAArch64OutlineAtomicsDefault in LLVM. Specifically, +outline-atomics is on by default on aarch64 targets for: fuschia (always) and linux (if the libgcc runtime lib is >= 9.3.1).

   In addition to that rustc_target turns it on by default for all(?) of the targets that would match cfg(all(target_arch = "aarch64", target_env = "gnu", target_os = "llvm")).

   As far as I can tell though, the stubs for outline-atomics are always compiled in on aarch64 targets, just in case a user wants to enable them via -Ctarget-feature=+outline-atomics. I suppose this is useful but causes quite a few problems. ↩

[thomcc]

That said: that none of this really impacts windows or macOS which don't have any particular need for these.

I don't know if compiler-rt's impls support them on Windows at all (if they do, we don't use them), and aarch64 apple targets don't seem to have them on either (the macOS ones statically the LSE feature available so there'd be no point, and while some of the other apple targets probably could use them, we don't turn +outline-atomics on for them, and I'm not about to suggest starting)

[thomcc]

CC @Amanieu who may have more nuanced thoughts here than I do.

[workingjubilee]

Hmm. @sebpop did not mention this disadvantage regarding the feature in the PR to add it. I thought this was handled purely through some other resolution mechanism. I would not have approved that PR if I had been made aware, as Rust's core libraries acquiring a dependency on libc is strictly unacceptable. It is an actual violation of our policies.

[jyn514]

marking this as blocked on #109064; once that's done we can change the default to optimized-builtins = false without causing inscrutable linker errors.

[ChrisDenton]

#109064 is completed so unblocking this.