Cargo non-deterministically rebuilding and failing to override with [replace]

[Ericson2314]

cargo build --target i686-unknown-linux-gnu with https://github.com/RustOS-Fork-Holding-Ground/RustOS/tree/3743e64e1db53e5822446c8c25ab7670cf590a75 seems to send Cargo haywire.

I use the [replace] section to substitute my own version of libraries with which explicitly depend on core. But dependencies will sometimes fail to be built because missing/duplicate core, indicating the [replace] did not work and it's either both linking the custom-built core and the one in the sysroot, or cannot find the one in the sysroot. Furthermore after building does succeed, it may seemingly at random try to rebuild dependencies again, in which case more [replace]-roulette.

Note that one does need the i686 sysroot installed to observe this---instead of sometimes succeeding, it will (as should be expected) make it to linking and then complain about missing compiler-rt.

Witnessed on the with the 2016-04-20 cargo and rust nighties.

[alexcrichton]

I unfortunately haven't had too much of a chance to dig into this yet, it will likely take awhile due to how much is in play. Can this be minimized at all to something that's easy to poke around?

[Ericson2314]

Yes it ought to be minimizable. I'll see what I can do.

[Ericson2314]

Ok, here is a my minimization: https://github.com/RustOS-Fork-Holding-Ground/RustOS/tree/minimize-cargo-error. the top commit fails every time, the others fail non-materialistically like the original.

[Ericson2314]

I am going to try with more recent Cargo now.

[Ericson2314]

Ok, problem confirmed on latest Cargo and RustC nightlies

[alexcrichton]

Sorry just getting around to this now, but by minimize I mean moreso the dependency graph rather than the code itself, would it be possible to get a smaller graph in play to reproduce?

[Ericson2314]

Hm now the original is failing 100% of the time on same nightly I think---I'm really confused.

In the top commit the dep graph should be pretty minimized---most of those overrides won't have any effect. The only immediate dependency is libcpu (which in turn just uses bitflags and core) which builds on its own, but doesn't when used as a dep here.

[Ericson2314]

Ok, I removed libcore's build script (is it actually needed?) to try building without any precompiled libs. I think the problem is [[replace]] breaks when the overriding package has deps the original package did not have: Cargo ignores those deps and doesn't pass any --extern flags for them.

I still have no idea where the non-determinism was coming from, but might be gone now.

[Ericson2314]

#2603 seems related.

[alexcrichton]

If this hasn't changed, it's still very difficult to debug and would be good to minimize. Random other issues probably aren't related just yet, especially #2603 which was never even confirmed as an issue?

[Ericson2314]

I'm about to head to sleep. I finally had the in hindsite obvious idea to look at the lock file. That disproves my previous theory---the replacement crates always have all their deps. But indeed the lockfile is non-deterministic and the failures occur precisely when the lockfile get's a weird reflexive replacement (but the target crate has branch instead of resolved rev). example:

[[package]]
name = "bitflags"
version = "0.6.0"
source = "git+https://github.com/RustOS-Fork-Holding-Ground/bitflags?branch=rustos#ec1dc15afca846ca7f871f029f8471f4b0364168"
replace = "bitflags 0.6.0 (git+https://github.com/RustOS-Fork-Holding-Ground/bitflags?branch=rustos)"

I'll work more on the minimal branch tomorrow.

[Ericson2314]

Minimized and converted to test QuiltOS@cffe45e :)

[Ericson2314]

Working on a fix.