Cargo should provide --remap-path-prefix or not hash it from RUSTFLAGS. #6914
Labels
C-feature-request
Category: proposal for a feature. Before PR, ping rust-lang/cargo if this is not `Feature accepted`
Comments
alexcrichton
added
the
C-feature-request
|
Can I petition to have this changed from "feature request" to "use-blocking bug"? I mean, it was working fine until it got broken. |
|
One workaround for this which I've forgotten to mention earlier is something like this: $ RUSTC=./my-rustc-wrapper.sh cargo buildand the contents of #!/bin/sh
exec rustc "$@" --remap-path-prefix ...and that will subvert Cargo's hashing. |
bors
added a commit
that referenced
this issue
Jun 6, 2019
Ignore remap-path-prefix in metadata hash. Including this flag in the metadata hash causes problems with reproducible builds. I spent some time considering the different alternatives (such as providing a config option, or an unhashed RUSTFLAGS alternative), and decided this might be the best option. - It is a very simple, small change. - It should be safe. - It is transparent to the user, they don't need to do anything special. - It doesn't expand Cargo's interface. Fixes #6914.
81 tasks
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
After #6503, reproducible build setups that were setting
RUSTFLAGS="--remap-path-prefix=..."in order to normalize paths in rustc, stopped being reproducible, as Cargo is now hashing the wholeRUSTFLAGSvalue, resulting in different-C metadatavalues.This was originally reported in rust-lang/rust#59542, and one of the solutions suggested there was that Cargo should provide its own
--remap-path-prefix, which would not be hashed, and that becomes the supported way set this flag.Another possibility could be Cargo parsing
--remap-path-prefixout ofRUSTFLAGS, before hashing the rest, but that seems perhaps a bit brittle.cc @michaelwoerister @Eh2406
The text was updated successfully, but these errors were encountered: