Stable crate hash depends on host tuple

[JakobDegen]

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

[saethlin]

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 Encodable matches its Decodable" with no real consistency between the way types implement them), this also came up recently in #113584

[Enselic]

Triage: #113584 is closed as fixed, so this issue can probably also be closed as fixed?