You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Previously, `rustc_fingerprint` was only using the path and mtime for
each executable, but this is not always sufficient. For example, Fedora
will [clamp mtimes] to help reproducible builds, so Rust 1.82 looks like
`/usr/bin/rustc` and `2024-10-17 00:00:00` across all builds in Fedora
39 through 42 (rawhide), even though they are different in their full
version strings, LLVM, etc.
[clamp mtimes]: https://fedoraproject.org/wiki/Changes/ReproducibleBuildsClampMtimes
If the target directory (including `.rustc_info.json`) is shared across
such systems, the fingerprint wouldn't notice the difference, and cargo
would try to use artifacts that aren't actually compatible, like:
```
error[E0514]: found crate `autocfg` compiled by an incompatible version of rustc
--> build.rs:2:14
|
2 | let ac = autocfg::new();
| ^^^^^^^
|
= note: the following crate versions were found:
crate `autocfg` compiled by rustc 1.82.0 (f6e511eec 2024-10-15) (Fedora 1.82.0-1.fc42): [...]/target/debug/deps/libautocfg-589c41db1eea6297.rlib
= help: please recompile that crate using this compiler (rustc 1.82.0 (f6e511eec 2024-10-15) (Fedora 1.82.0-1.fc40)) (consider running `cargo clean` first)
```
We can improve this situation by adding the file length, although that
could also happen to be the same, and the creation date that will match
when the file was installed, though not all filesystems support that.
All of this comes from a single metadata call, so it shouldn't have any
noticeable slowdown that would hurt the caching effort.
0 commit comments