-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
x.py
panics when trying to build "stage3" compiler
#90244
Comments
cc @jyn514 -- I think this is caused by the move of compiler assembly into the rustc step (or similar). I think the fix here is likely to make sure the code is reading from stage1-rustc's stamp file if it's reusing those libraries. We may also prefer to just skip the copy entirely -- stage3/bin/rustc is not generally useful -- but that should get gated on full-bootstrap if it still exists (I forget). |
My understanding is that stage3 is still useful for ensuring we have reproducible builds. Yes, full-bootstrap still exists (although I'm not sure what the use case is). |
Independent of whether stage 3 exists or not, the command here explicitly asks for stage 2 so something seems to have gone wrong when stage 3 steps are happening. This problem still persists in current master, I just ran into it with |
Since you've already built the stage 3 compiler (in all but copying it into place), it makes some sense to assemble it. At least, this more closely matches the likely-desired behavior at earlier stages, IMO. I'd be fine with us just adding a stage == 3 and not full-bootstrap bailout to this code for now, which should mitigate this error, or a more complete patch -- I think reverting #89759 is probably not the right patch, though. |
Have I? All I want is a stage 2 that I can use to build Miri. From what you said it sounds like |
Hm, no, it does not since Miri needs the rustc libs themselves. |
Without full-bootstrap, stages >= 2 don't actually have distinct libraries (we uplift the stage 1 compiler artifacts). So in some sense any stage is "built" and copy-able into the relevant directories once you have a stage2/bin/rustc. But, yes, you do need to copy the rustc libraries into the appropriate sysroot. I suspect that your particular use case may be painful/unworkable with the stage 3 assembly step being broken (as noted in this issue), but am not sure. |
Well, running |
What is the proper way to build the stage2 compiler now? Copying stage1 rustc from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) |
|
Yeah, the error is just annoying; it doesn't actually break anything. |
I think I found the issue. The stamp file is written in Line 1377 in f6cef57
|
This is kind of tricky to fix, because everywhere in bootstrap that touches |
That won't actually help with #96798 though :( but as I posted on that PR, I think we should never be trying to use the stage 3 sysroot anyway. |
Clarified issues when building miri with a custom rustc I came across these issues (see zulip threads [here](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/.E2.9C.94.20Changes.20not.20in.20effect) and [here](https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Missing.20.2Elibrustc.2Estamp), issue [here](rust-lang/rust#90244)) and would like to add this small bit to the docs. Feel free to change the wording.
While ignoring the issue might work for manual builds, it certainly is not trivial to ignore this error for automated build systems or package build systems (debbuild). Might be worth providing a doc on this and adding a workaround, as most would not be building manually for distros or from source CI/CD automation. config.toml: ./x.py build --stage 2 -j12 works. librustc_macros-*.so is no longer present in the lib directory. Was that removed/depreciated from the compiler build? |
FWIW that does not seem to be always true; when using multi-step |
@rustbot claim |
@RalfJung (and others who come across this issue), there's this note in bootstraping docs about the unintuitive behavior of this flag:
Perhaps it would be good to replicate it in chapter 1. How to build and run the compiler. |
please no, that chapter is already long enough and bootstrapping is too complicated to try to summarize it in a single sentence |
Also this bug is not caused by a user misunderstanding the stage numbering, it is caused by x.py not treating that stage correctly. |
I can't reproduce this anymore even with #108288 reverted. Would it be ok to revert that PR? |
If revert isn't blocking any other stuff, I would like to spend some time to understand the underlying reason. |
It isn't. I just noticed this issue being referenced while reading the bootstrap code and figured I did try if I could remove the special case. |
Problem still exists actually. change-id = 102579
profile = "compiler"
[llvm]
download-ci-llvm = true
[build]
docs = false
docs-minification = false
compiler-docs = false
[rust]
download-rustc = false
deny-warnings = false
|
I don't think there even is a stage3, so I think this is a bug in bootstrap. I haven't encountered this before. Rerunning the command produces the same panic. Despite the panic,
rustc +r2stage2 --help
works, presumably because the build has finished andx.py
is trying to do extra steps by building a non-existent stage.In case it helps, my branch's merge-base is 00d5e42. My branch only modifies the Miri engine, so I'm pretty sure it's unrelated to this bug.
Backtrace
The text was updated successfully, but these errors were encountered: