Repository navigation
Stable crate hash depends on host tuple #113990
Description
A full reproducer for this creating an end-to-end issue can be found by executing ./run.sh here. Note that the script assumes x86-64-unknown-linux-gnu and probably requires first running the rustup commands commented out at the top.
Running it currently gets me, on both stable and nightly:
$ ./run.sh
error[E0460]: found possibly newer version of crate `p` which `l` depends on
--> b.rs:4:5
|
4 | l::foo();
| ^
|
= note: perhaps that crate needs to be recompiled?
= note: the following crate versions were found:
crate `p`: /tmp/fun-with-cross-compilation/build/libp.rlib
crate `l`: /tmp/fun-with-cross-compilation/build/libl.rlib
error[E0463]: can't find crate for `l`
--> b.rs:5:5
|
5 | l::p();
| ^ can't find crate
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0460, E0463.
For more information about an error, try `rustc --explain E0460`.
My guess is that the root cause of this problem is significantly worse on nightly than on stable:
On nightly:
$ hexdump build/libp.rlib > /tmp/a
$ hexdump buildb/libp.rlib > /tmp/b
$ diff /tmp/a /tmp/b | wc -l
758
While on stable:
$ hexdump build/libp.rlib > /tmp/a
$ hexdump buildb/libp.rlib > /tmp/b
$ diff /tmp/a /tmp/b | wc -l
2
cc @saethlin , this makes me think it's related to your changes
Meta
$ rustc +nightly-x86_64-unknown-linux-gnu --version --verbose
rustc 1.73.0-nightly (8771282d4 2023-07-23)
binary: rustc
commit-hash: 8771282d4e7a5c4569e49d1f878fb3ba90a974d0
commit-date: 2023-07-23
host: x86_64-unknown-linux-gnu
release: 1.73.0-nightly
LLVM version: 16.0.5
$ rustc +stable-x86_64-unknown-linux-gnu --version --verbose
rustc 1.71.0 (8ede3aae2 2023-07-12)
binary: rustc
commit-hash: 8ede3aae28fe6e4d52b38157d7bfe0d3bceef225
commit-date: 2023-07-12
host: x86_64-unknown-linux-gnu
release: 1.71.0
LLVM version: 16.0.5
Activity
saethlin commentedon Jul 24, 2023
Yeah I've definitely perturbed the crate metadata a bit recently, this PR seems the most likely #110367
But this one also changed the crate metadata format a lot #110083
(I've also made other changes but those two seem the most likely to be encountered in looking into this)
FWIW, crate metadata is basically not introspectable (the format is just "this type's
Encodablematches itsDecodable" with no real consistency between the way types implement them), this also came up recently in #113584Enselic commentedon Nov 27, 2024
Triage: #113584 is closed as fixed, so this issue can probably also be closed as fixed?
[-]Stable crate hash depends on host target[/-][+]Stable crate hash depends on host tuple[/+]