rlibs are not bit-identical when building the same crate in different directories with -Zremap-path-prefix #48019
Comments
TimNN
added
C-enhancement
|
Lots of stuff goes into the SVH. It might well be that something directory related accidentally goes into it. The SVH is computed here: rust/src/librustc/hir/map/collector.rs Lines 123 to 163 in 16362c7 |
|
cc #34902 This is similar to the GCC build-path issue where other programs (and in the past, GCC's DW_AT_producer) likes to embed CFLAGS into the output. Suggested options:
|
|
#48162 addresses (1), which is kind of orthogonal to (2) and (3) because the SVH will always be part of the output binary and it must change if the result of the mapping changes. |
…omatsakis Handle path prefix mapping in a more stable way when computing the crate hash This hopefully fixes issue rust-lang#48019. cc @luser @infinity0
|
With the latest Rust nightly: which includes the fix from #48162, the outputs from my test script are still not the same: |
|
I think we may still be hashing |
|
Yes, it seems we do: rust/src/librustc/session/config.rs Line 396 in 27a046e Good catch! Not sure if we have to hash those at this point. The tracking system should catch resulting changes later on, if we don't have any holes in the tracking. This needs some review. |
|
Edit: never mind - seems fixed now that I've rebased to master. I found that (after implementing it) will generate different metadata hashes if I change the mapping, even though it doesn't affect anything and nothing else changes. |
Currently rustc isn't always the best at producing deterministic builds of a crate when the source directory of a crate is changed. This is happening due to what appears two different sources: * First the `-L` paths passed to rustc are hashed into the crate hash. These paths through Cargo are typically absolute paths that can vary if the build directory changes. * Next the paths passed to `--extern` are also hashed which like `-L` can change if the build directory changes. This commit fixes these two sources of nondeterminism by ensuring that avoiding tracking the hashes of these arguments on the command line. For `-L` paths they're either related to loading crates (whose hashes are tracked elsewhere) or native librarise used in the linking phase (which isn't incremental). The `--extern` paths are similar in that they're related to crate resolution which is already tracked independently of the command line arguments. Closes rust-lang#48019
I was trying to determine if sccache could cache crates built as dependencies of different root crates. When I looked into it I found that the rlibs were not bit-identical despite being built from the same source. Most of the differences were in the debug info because the current directory winds up encoded there. I tried using
-Zremap-path-prefix-from=... -Zremap-path-prefix-to=...which removed most of the differences but not all. A small difference in the metadata remains, which from looking at the diff of the serialized metadata @eddyb said was the SVH. @michaelwoerister: do you know why this would be?I built this test crate twice in different directories using the test-build.sh script. The diff of the
itoarlib from each build looks like this (I generated that using diffoscope.)Presumably this would block #34902 and also #38322.
The text was updated successfully, but these errors were encountered: