Stream: general

Topic: "incompatible version of rustc" when using `--keep-stage`


RalfJ (Feb 28 2020 at 10:53, on Zulip):

When working on miri against a locally built rustc, I use an invocation like ./x.py build src/rustc --keep-stage 0 because without keep-stage, the edit-compile cycle involves a full clean compiler build and two builds of librustc_mir (sometimes even two builds of librustc) and easily takes >20min. This used to work fine, but it looks like something changed (semi-)recently and now I often end up with errors like

error[E0514]: found crate `std` compiled by an incompatible version of rustc
  |
  = help: please recompile that crate using this compiler (rustc 1.43.0-nightly (c52d85610 2020-02-28))
  = note: the following crate versions were found:
          crate `std` compiled by rustc 1.43.0-nightly (1fec68277 2020-02-28): /home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-9a44f0c4a069c23d.rlib
          crate `std` compiled by rustc 1.43.0-nightly (1fec68277 2020-02-28): /home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-9a44f0c4a069c23d.so

this happens whenever I do git commit or a night passes since I did my last non-keep-stage build, and it makes my work quite painful.
is there any work-around, or does someone know why this was not a problem earlier (like, last year)?
a possible work-around would be to build a stage 2 libstd instead of "Uplifting stage1 std", but I don't know how to trigger that.

RalfJ (Feb 28 2020 at 10:58, on Zulip):

commenting out the std uplifting logic works around this successfully:

diff --git a/src/bootstrap/compile.rs b/src/bootstrap/compile.rs
index 7dded96e18e..ff5cd87481f 100644
--- a/src/bootstrap/compile.rs
+++ b/src/bootstrap/compile.rs
@@ -66,7 +66,7 @@ impl Step for Std {

         let mut target_deps = builder.ensure(StartupObjects { compiler, target });

-        let compiler_to_use = builder.compiler_for(compiler.stage, compiler.host, target);
+        /*let compiler_to_use = builder.compiler_for(compiler.stage, compiler.host, target);
         if compiler_to_use != compiler {
             builder.ensure(Std { compiler: compiler_to_use, target });
             builder.info(&format!("Uplifting stage1 std ({} -> {})", compiler_to_use.host, target));
@@ -81,7 +81,7 @@ impl Step for Std {
                 target,
             });
             return;
-        }
+        }*/

         target_deps.extend(copy_third_party_objects(builder, &compiler, target).into_iter());

so maybe that should be an option, or maybe --keep-stage should trigger that (though I probably still want rustc uplifting), or so?

RalfJ (Feb 28 2020 at 10:59, on Zulip):

oh never mind, that just triggers another similar failure later:

error[E0514]: found crate `rustc_apfloat` compiled by an incompatible version of rustc
  --> src/lib.rs:10:1
   |
10 | extern crate rustc_apfloat;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = help: please recompile that crate using this compiler (rustc 1.43.0-nightly (c52d85610 2020-02-28))
   = note: the following crate versions were found:
           crate `rustc_apfloat` compiled by rustc 1.43.0-nightly (1fec68277 2020-02-28): /home/r/src/rust/rustc.2/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_apfloat-abb1b5f86bb36b4a.rlib
simulacrum (Feb 28 2020 at 12:42, on Zulip):

hm, are those errors during bootstrap itself? at what stage? I would not expect to see -nightly as the compiler at any point during bootstrap

simulacrum (Feb 28 2020 at 12:42, on Zulip):

what you're trying to do is get a stage 2 compiler, right?

RalfJ (Feb 28 2020 at 12:47, on Zulip):

sorry I should have said: those are errors I get when building miri against the stage2 compiler

RalfJ (Feb 28 2020 at 12:48, on Zulip):

building stage2 works, but the resulting stage2 is useless because it considers itself incompatible with its own libstd

RalfJ (Feb 28 2020 at 12:48, on Zulip):

(yes I did rm target -rf on the miri side)

simulacrum (Feb 28 2020 at 12:52, on Zulip):

oh, hm

simulacrum (Feb 28 2020 at 12:52, on Zulip):

are you sure you're building with stage 2? Maybe your editor is messing with the target directory (e.g., cargo check running in the background?)

simulacrum (Feb 28 2020 at 12:52, on Zulip):

What does stage/bin/rustc -vV give?

simulacrum (Feb 28 2020 at 12:53, on Zulip):

I would expect -dev as the "toolchain" whereas you seem to be getting interference from a nightly toolchain

simulacrum (Feb 28 2020 at 12:53, on Zulip):

@RalfJ ^

RalfJ (Feb 28 2020 at 12:56, on Zulip):

simulacrum said:

are you sure you're building with stage 2? Maybe your editor is messing with the target directory (e.g., cargo check running in the background?)

I am doing this directly on the console, rustup show says "rustc.2-s2 (directory override for '/home/r/src/rust/miri')" is active

RalfJ (Feb 28 2020 at 12:57, on Zulip):

simulacrum said:

I would expect -dev as the "toolchain" whereas you seem to be getting interference from a nightly toolchain

ooohhhhh

RalfJ (Feb 28 2020 at 12:57, on Zulip):

yeah I had set channel = "nightly" ages ago as that is required to test build-manifest, and forgot to change it back :/

RalfJ (Feb 28 2020 at 12:58, on Zulip):

@simulacrum thanks, that drove me in the right direction

simulacrum (Feb 29 2020 at 00:13, on Zulip):

@RalfJ I am amazed that helped if you had already set the toolchain as nightly :)

RalfJ (Feb 29 2020 at 08:36, on Zulip):

the rustup toolchain was right all along

RalfJ (Feb 29 2020 at 08:36, on Zulip):

just, my locally compiled rustc was compiled as "nightly" instead of the usual "dev"

Last update: May 29 2020 at 16:45UTC