Change:
// when not performing a full bootstrap). builder.ensure(Rustc::new(build_compiler, target_compiler.host)); <ins> // FIXME: For now patch over problems noted in #90244 by early returning here, even though // we've not properly assembled the target sysroot. A full fix is pending further investigation, // for now full bootstrap usage is rare enough that this is OK. if target_compiler.stage >= 3 && !builder.config.full_bootstrap { return target_compiler; } </ins> for &backend in builder.config.rust_codegen_backends.iter() { if backend == "llvm" { continue; // Already built as part of rustc

Discussion:
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, works, presumably because the build has finished and is trying to do extra steps by building a non-existent stage. In case it helps, my branch's merge-base is . My branch only modifies the Miri engine, so I'm pretty sure it's unrelated to this bug. <details<summaryBacktrace</summary</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc -- 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 .
for context this is likely caused by - I'm ok with reverting that for now if bootstrap has other bugs, but I don't think assembling the compiler before you've asked for it is inherently a bug.
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 is probably not the right patch, though.
Have I? All I want is a stage 2 that I can use to build Miri.

seemed like the easiest way to do that. I guess this will also build the 'stage2 compiler artifacts' (aka the stage 3 compiler), but that is just a copy so I don't mind this extra work. From what you said it sounds like should suffice for my usecase?
Hm, no, it does not since Miri needs the rustc libs themselves. does the extra work of putting those into the stage 2 sysroot, it seems.
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 and then just ignoring the fact that it panics seems to be good enough to build Miri. But yeah something is wrong, as the panic shows.^^
What is the proper way to build the stage2 compiler now?

With 1.57.0, x.py build --stage 2 compiler/rustc Copying stage1 rustc from stage1 (x8664-unknown-linux-gnu -x8664-unknown-linux-gnu / x8664-unknown-linux-gnu) Assembling stage2 compiler (x8664-unknown-linux-gnu) Uplifting stage1 std (x8664-unknown-linux-gnu -x8664-unknown-linux-gnu) Copying stage2 std from stage1 (x8664-unknown-linux-gnu -x8664-unknown-linux-gnu / x8664-unknown-linux-gnu) Uplifting stage1 rustc (x8664-unknown-linux-gnu -x8664-unknown-linux-gnu) Copying stage2 rustc from stage1 (x8664-unknown-linux-gnu -x8664-unknown-linux-gnu / x8664-unknown-linux-gnu) Assembling stage3 compiler (x8664-unknown-linux-gnu) thread 'main' panicked at 'fs::read(stamp) failed with No such file or directory (os error 2) ("/home/chaasmadmin/nimbus8/rust/rust-chaasm-1.57.0/rust/build/x8664-unknown-linux-gnu/stage2-rustc/x8664-unknown-linux-")', note: run with environment variable to display a backtrace Build completed unsuccessfully in 5:08:19
works for me, you just have to ignore the error.
Yeah, the error is just annoying; it doesn't actually break anything.
I think I found the issue. The stamp file is written in , but for stage 2 we just copy the files rather than rebuilding a third time.
This is kind of tricky to fix, because everywhere in bootstrap that touches or suddenly needs to know whether those artifacts actually exist or whether we're reusing the ones from stage 1. I think a simpler fix is just to avoid assembling the sysroot for stage 3 and up.
That won't actually help with though :( but as I posted on that PR, I think we should never be trying to use the stage 3 sysroot anyway.
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. extended = true tools = ["cargo"] 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 invocations such as this error causes later steps to be skipped, which becomes an .
claim
(and others who come across this issue), there's this note in about the unintuitive behavior of this flag: Perhaps it would be good to replicate it in .
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 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. panics.