-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rustc-driver binary is not identical for every build #102299
Comments
I noticed the path-name contains /incremental/. Is this also an issue when incremental compilation is off? |
The 'incremental' path is autogenerated in build directory, this object file is generated during the 'stage-0' and still 'stage-1' is yet to build, so I guess in that way the build is 'incremental'? Is there any option that can avoid this? |
This comment was marked as resolved.
This comment was marked as resolved.
I think it's specifically the build path that's embedded, this is a known limitation at the moment and projects like Arch Linux that are currently doing reproducible builds use a standardized build path to reproduce their rust binaries (and the rust compiler itself). It would be nice to have rust/cargo not embed the build path by default (that's why I've filed rust-lang/cargo#5505) but it doesn't block the security advantages of reproducible builds. |
@kpcyrd Thanks for the info... Is there a way available to eliminate build paths in final binary? I tried a few ways with |
This has worked for me in the past:
I had a CI job in place that uses reprotest like this: https://github.com/kpcyrd/sniffglue/blob/main/ci/reprotest.sh |
It sounds like this is avoidable using --remap-path-prefix, so I'm going to close this issue. The issue tracker is not a support forum. For future questions please ask in one of these places: https://discord.gg/rust-lang/ |
Rustc still does not have complete support for fully reproducible builds (rust-lang/rust#75362). Attempt to narrow the gap by following the advice from (rust-lang/rust#102299) and overwrite all panic paths with a different, consistent value.
Rustc still does not have complete support for fully reproducible builds (rust-lang/rust#75362). Attempt to narrow the gap by following the advice from (rust-lang/rust#102299) and overwrite all panic paths with a different, consistent value.
Rustc still does not have complete support for fully reproducible builds (rust-lang/rust#75362). Attempt to narrow the gap by following the advice from (rust-lang/rust#102299) and overwrite all panic paths with a different, consistent value.
Rustc still does not have complete support for fully reproducible builds (rust-lang/rust#75362). Attempt to narrow the gap by following the advice from (rust-lang/rust#102299) and overwrite all panic paths with a different, consistent value.
Rustc still does not have complete support for fully reproducible builds (rust-lang/rust#75362). Attempt to narrow the gap by following the advice from (rust-lang/rust#102299) and overwrite all panic paths with a different, consistent value. Changes: * Use --remap-path-prefixes to make paths consistent. * Set build path to /tmp/build-yhm. * Include Cargo.lock files to compile the same dependencies.
Rustc still does not have complete support for fully reproducible builds (rust-lang/rust#75362). Attempt to narrow the gap by following the advice from (rust-lang/rust#102299) and overwrite all panic paths with a different, consistent value. Changes: * Use --remap-path-prefixes to make paths consistent. * Set build path to /tmp/build-yhm. * Include Cargo.lock files to compile the same dependencies.
Rustc still does not have complete support for fully reproducible builds (rust-lang/rust#75362). Attempt to narrow the gap by following the advice from (rust-lang/rust#102299) and overwrite all panic paths with a different, consistent value. Changes: * Use --remap-path-prefixes to make paths consistent. * Set build path to /tmp/build-yhm. * Include Cargo.lock files to compile the same dependencies.
Rustc still does not have complete support for fully reproducible builds (rust-lang/rust#75362). Attempt to narrow the gap by following the advice from (rust-lang/rust#102299) and overwrite all panic paths with a different, consistent value. Changes: * Use --remap-path-prefixes to make paths consistent. * Set build path to /tmp/build-yhm. * Include Cargo.lock files to compile the same dependencies.
The rust build output [[build-dir]]/x86_64-unknown-linux-gnu/stage1/lib/librustc_driver-67046b4f71f47f00.so is not identical for every build. I debugged the issue by comparing all the generated object files between two different builds, the object file '[[build-dir]]/bootstrap/debug/incremental/bootstrap-22qjf7qknjduo/s-gdrx5ab0wu-1spyacv-3unuz3kev23rs/4oqq7pii1co5y8sx.o' is different between two builds. This object file .rodata section is holding the filename with path, and when the path is changed this section is getting chaged and causing final .so file to be changed.
Below is the contents of .rodata section from two build directories.
.rodata section in build directory : build-1
:~/rust/build-1$ objdump -s -j .rodata..L__unnamed_34 ~/rust/build-1/bootstrap/debug/incremental/bootstrap-22qjf7qknjduo/s-gdrx5ab0wu-1spyacv-3unuz3kev23rs/4oqq7pii1co5y8sx.o
/home/skokkonda/rust/build-1/bootstrap/debug/incremental/bootstrap-22qjf7qknjduo/s-gdrx5ab0wu-1spyacv-3unuz3kev23rs/4oqq7pii1co5y8sx.o: file format elf64-x86-64
.rodata section in build directory : build-test
:~/rust/build-1$ objdump -s -j .rodata..L__unnamed_34 ~/rust/build-test/bootstrap/debug/incremental/bootstrap-22qjf7qknjduo/s-gds2uitpgl-fm0ssi-193tjef7tbwwd/4oqq7pii1co5y8sx.o
/home/skokkonda/rust/build-test/bootstrap/debug/incremental/bootstrap-22qjf7qknjduo/s-gds2uitpgl-fm0ssi-193tjef7tbwwd/4oqq7pii1co5y8sx.o: file format elf64-x86-64
I tried two different builds with identical build path and then compared the binaries, those are identical.
This issue is causing a automated test failure in Yocto build enevironment. Can anyone confirm that is it a bug in rust?
The text was updated successfully, but these errors were encountered: