xargo build fails after using stale dependencies built against different version of 'core'

[robert-w-gries]

I have been seeing this error message in various kernel projects that use xargo:

   Compiling core v0.0.0 (file:///home/rob/.rustup/toolchains/nightly-2017-12-23-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcore)
   Compiling std_unicode v0.0.0 (file:///home/rob/.rustup/toolchains/nightly-2017-12-23-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libstd_unicode)
   Compiling alloc v0.0.0 (file:///home/rob/.rustup/toolchains/nightly-2017-12-23-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/liballoc)
    Finished release [optimized] target(s) in 24.22 secs
   Compiling compiler_builtins v0.1.0 (file:///home/rob/.rustup/toolchains/nightly-2017-12-23-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/src/libcompiler_builtins)
    Finished release [optimized] target(s) in 2.45 secs
    Updating git repository `https://github.com/japaric/utest`
    Updating registry `https://github.com/rust-lang/crates.io-index`            
   Compiling rxinu v0.1.0 (file:///home/rob/rxinu)
error[E0460]: found possibly newer version of crate `core` which `bitflags` depends on
  --> src/lib.rs:18:1
   |
18 | extern crate bitflags;
   | ^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: perhaps that crate needs to be recompiled?
   = note: the following crate versions were found:
           crate `core`: /home/rob/.xargo/lib/rustlib/x86_64-rxinu/lib/libcore-0671f1c158fe3776.rlib
           crate `bitflags`: /home/rob/rxinu/target/x86_64-rxinu/debug/deps/libbitflags-bed2609b99acd464.rlib

Example A
Example B

Reproducing the problem

I did some triage over in phil-opp/blog_os#378. Here's what I found.

This looks like an issue where xargo or cargo attempts to re-use stale dependencies built against a different version of core.

The issue is intermittent in Travis, which makes debugging difficult. However, I recently discovered how to trigger the issue locally by setting my Xargo.toml as follows

[dependencies.alloc]
stage = 0

[dependencies.compiler_builtins]
stage = 1

I then run the following commands in my rxinu project directory:

git checkout feature/i686-scheduling
make clean
make
git checkout feature/test-framework
make  # `xargo build` fails until we run `make clean`

[japaric]

I've noticed this since like a month ago but haven't been able to generate a minimal reproduction steps.

This looks like an issue where xargo or cargo attempts to re-use stale dependencies built against a different version of core.

I think something in Cargo "fingerprint" mechanism may have recently changed that it's making it no longer rebuild dependencies when the Xargo sysroot contents change.

[japaric]

The issue is intermittent in Travis

I've experienced Travis build failures too. I have had some luck enabling caching of the Xargo sysroot ($HOME/.xargo) directory.

[phil-opp]

I think something in Cargo "fingerprint" mechanism may have recently changed

There were some fingerprinting changes in rust-lang/cargo#4788, maybe that's the problem.

I have had some luck enabling caching of the Xargo sysroot ($HOME/.xargo) directory.

You mean addionally caching $HOME/.xargo (like in the steed .travis.yml) solves the problem?

[phil-opp]

Minimal reproduction steps:

1. Compile project using xargo.
2. Copy the project somewhere else.
3. Recompile it.

[chris13524]

Also getting this error. Reproduction steps:

Install Docker and QEMU (although QEMU probably isn't necessary)

git clone --recurse-submodules git@github.com:projectasiago/asiago.git
cd asiago
make run-aura

Wait for QEMU to start, then close it.

Add a semicolon or change something in aura/src/lib.rs

Run make run-aura

I'm guessing this is because the environment that libcore was built in has now changed...or something.

[coolreader18]

Ah ok, there were parallel make builds occuring, and when I gave each job a different XARGO_HOME that resolved the issue. Maybe flock is broken?

Edit: actually I have no idea what fixed it, I didn't actually set XARGO_HOME properly. Maybe the parallel builds are the issue, but it's just flaky? Cause I think maybe it only locked it while it was compiling the sysroot crate, but after that the next build could come in and clear the xargo dir.