Open jonhoo opened 6 years ago
It also sounds very similar to #36852 (except it occurs with incremental turned off), which suggests it's a bug in the codegen partitioning code.
Another data-point:
$ env CARGO_INCREMENTAL=0 RUSTFLAGS='-C codegen-units=1' cargo b --release --bin souplet
...
Compiling dataflow v0.1.0 (file:///home/jon/dev/distributary/dataflow)
Compiling mir v0.1.0 (file:///home/jon/dev/distributary/mir)
Compiling distributary v0.1.0 (file:///home/jon/dev/distributary)
Finished release [optimized + debuginfo] target(s) in 10m 36s
So this is indeed related to multiple codegen units.
I have a larger application called
distributary
that encounters a linking error on current nightly when you try to compile mit-pdos/distributary@216ec42058b962727974ac7a0d43c84097f3f73d (also occurs on earlier commits) in release mode with incremental compilation turned off:Interestingly, it links just fine incremental compilation turned on:
It also compiles fine in debug mode with incremental compilation turned off:
The issue also occurs after
cargo clean
. Unfortunately, due to some NLL issues in past nightlies (#51348 and #51649), bisecting nightlies this isn't trivial. I've also tried producing a minimized reproducing example, but to no avail. This could be a dupe of #47989, although I don't immediately see any duplicated linking targets. Scanning through cargo's output with--verbose
, it also looks like the number of linked objects in debug vs release are the same.https://github.com/mit-pdos/distributary/tree/216ec42058b962727974ac7a0d43c84097f3f73d