Binaries end up containing path to the rust-src component despite --remap-path-prefix · Issue #73167 · rust-lang/rust (original) (raw)
When the following code is built with rustc with rust-src component available to it, the binary will end up containing the reference to the libstd source in the rustc installation path. This reference is then possibly printed out if this program panics if an error ever occurs.
fn main() { std::thread::spawn(|| { println!("hello"); }); }
Compile this program as such:
and inspect the executable with strings:
$ strings ./main | grep lib/rustlib
failed to spawn thread/nix/store/blyf5kcrmi9kciffk18qm9r6xr9k4c6v-rust-1.45.0-nightly-2020-06-04-47c3158c3/lib/rustlib/src/rust/src/libstd/thread/mod.rs
there is no such thing as a relaxed fence/nix/store/blyf5kcrmi9kciffk18qm9r6xr9k4c6v-rust-1.45.0-nightly-2020-06-04-47c3158c3/lib/rustlib/src/rust/src/libcore/macros/mod.rs
Then try to get rid of the source paths with the flag dedicated for exactly this purpose:
$ rustc src/main.rs --remap-path-prefix=/nix/store/blyf5kcrmi9kciffk18qm9r6xr9k4c6v-rust-1.45.0-nightly-2020-06-04-47c3158c3/lib/rustlib/src/=/rustc-src/
and notice that the binary contains the path to the original directory anyway:
$ strings ./main | grep lib/rustlib
failed to spawn thread/nix/store/blyf5kcrmi9kciffk18qm9r6xr9k4c6v-rust-1.45.0-nightly-2020-06-04-47c3158c3/lib/rustlib/src/rust/src/libstd/thread/mod.rs
there is no such thing as a relaxed fence/nix/store/blyf5kcrmi9kciffk18qm9r6xr9k4c6v-rust-1.45.0-nightly-2020-06-04-47c3158c3/lib/rustlib/src/rust/src/libcore/macros/mod.rs
The relevant logic appears to be here:
https://github.com/rust-lang/rust/blob/master/src/librustc_metadata/rmeta/decoder.rs#L1450
However it is not clear to me that this is the right place to introduce more logic to handle --remap-path-prefix.
Version
nightly 2020-06-05