-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bootstrap cannot check library/std for windows from macOS (and possibly others) #101172
Comments
@thomcc how did you get that far in the build? When I try it I get
|
|
To reproduce this I also needed to have the llvm submodule checked out so Line 319 in ed37111
|
…tins, r=Mark-Simulacrum Make the `c` feature for `compiler-builtins` an explicit opt-in Its build script doesn't support cross-compilation. I tried fixing it, but the cc crate itself doesn't appear to support cross-compiling to windows either unless you use the -gnu toolchain: ``` error occurred: Failed to find tool. Is `lib.exe` installed? ``` Fixes rust-lang#101172.
…iltins, r=jyn514 Revert "Make the `c` feature for `compiler-builtins` opt-in instead of inferred" This reverts commit 3acb505 (PR rust-lang#101833). The changes in this commit caused several bugs/incompatibilities (rust-lang#101833 (comment), rust-lang#102560). For now we're reverting this commit and will re-land it alongside fixes for those bugs. Re-opens rust-lang#101172 cc rust-lang#102560 cc rust-lang#102579
You can simply run Details
|
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 |
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 |
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 I opened #102579 to try and fix all those three things, but it's currently stuck on whether the default should be @thomcc says he's seen the error message for |
@thomcc says we can't turn off |
It doesn't effect ABI (these aren't __sync builtins), the issues are that:
So, maybe we should port them to compiler-builtins with 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 In theory we could compile in a 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
|
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 |
CC @Amanieu who may have more nuanced thoughts here than I do. |
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. |
marking this as blocked on #109064; once that's done we can change the default to |
#109064 is completed so unblocking this. |
…tins, r=onur-ozkan Reland optimized-compiler-builtins config Copy of rust-lang#102579 PR. From rust-lang#102579: > No concerns on my side. Currently, Jyn isn't actively working on the project. I will close this PR; open another one to cherry-pick the commits, resolve conflicts, and then r+ it. > Fixes rust-lang#102560. Fixes rust-lang#101172. Helps with rust-lang#105065 (although there's some weirdness there - it's still broken when optimized-compiler-builtins is set to true). Fixes rust-lang#102560. Fixes rust-lang#101172. Helps with rust-lang#105065 r? ghost
…ns, r=onur-ozkan Reland optimized-compiler-builtins config Copy of rust-lang#102579 PR. From rust-lang#102579: > No concerns on my side. Currently, Jyn isn't actively working on the project. I will close this PR; open another one to cherry-pick the commits, resolve conflicts, and then r+ it. > Fixes rust-lang#102560. Fixes rust-lang#101172. Helps with rust-lang#105065 (although there's some weirdness there - it's still broken when optimized-compiler-builtins is set to true). Fixes rust-lang#102560. Fixes rust-lang#101172. Helps with rust-lang#105065 r? ghost
…r-ozkan Reland optimized-compiler-builtins config Copy of #102579 PR. From #102579: > No concerns on my side. Currently, Jyn isn't actively working on the project. I will close this PR; open another one to cherry-pick the commits, resolve conflicts, and then r+ it. > Fixes rust-lang/rust#102560. Fixes rust-lang/rust#101172. Helps with rust-lang/rust#105065 (although there's some weirdness there - it's still broken when optimized-compiler-builtins is set to true). Fixes rust-lang/rust#102560. Fixes rust-lang/rust#101172. Helps with rust-lang/rust#105065 r? ghost
…r-ozkan Reland optimized-compiler-builtins config Copy of #102579 PR. From #102579: > No concerns on my side. Currently, Jyn isn't actively working on the project. I will close this PR; open another one to cherry-pick the commits, resolve conflicts, and then r+ it. > Fixes rust-lang/rust#102560. Fixes rust-lang/rust#101172. Helps with rust-lang/rust#105065 (although there's some weirdness there - it's still broken when optimized-compiler-builtins is set to true). Fixes rust-lang/rust#102560. Fixes rust-lang/rust#101172. Helps with rust-lang/rust#105065 r? ghost
…k-Simulacrum Make the `c` feature for `compiler-builtins` an explicit opt-in Its build script doesn't support cross-compilation. I tried fixing it, but the cc crate itself doesn't appear to support cross-compiling to windows either unless you use the -gnu toolchain: ``` error occurred: Failed to find tool. Is `lib.exe` installed? ``` Fixes rust-lang/rust#101172.
…k-Simulacrum Make the `c` feature for `compiler-builtins` an explicit opt-in Its build script doesn't support cross-compilation. I tried fixing it, but the cc crate itself doesn't appear to support cross-compiling to windows either unless you use the -gnu toolchain: ``` error occurred: Failed to find tool. Is `lib.exe` installed? ``` Fixes rust-lang/rust#101172.
…r-ozkan Reland optimized-compiler-builtins config Copy of #102579 PR. From #102579: > No concerns on my side. Currently, Jyn isn't actively working on the project. I will close this PR; open another one to cherry-pick the commits, resolve conflicts, and then r+ it. > Fixes rust-lang/rust#102560. Fixes rust-lang/rust#101172. Helps with rust-lang/rust#105065 (although there's some weirdness there - it's still broken when optimized-compiler-builtins is set to true). Fixes rust-lang/rust#102560. Fixes rust-lang/rust#101172. Helps with rust-lang/rust#105065 r? ghost
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 whereaarch64-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".
The text was updated successfully, but these errors were encountered: