Skip to content
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

Non-reproducible builds depending on the compiling OS #71361

Closed
gendx opened this issue Apr 20, 2020 · 3 comments
Closed

Non-reproducible builds depending on the compiling OS #71361

gendx opened this issue Apr 20, 2020 · 3 comments
Labels
A-reproducibility Area: Reproducible / deterministic builds C-bug Category: This is a bug. T-cargo Relevant to the cargo team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@gendx
Copy link

gendx commented Apr 20, 2020

Tock is an operating system written in Rust for embedded platforms (e.g. Cortex-M, RISC-V). We've been trying to make builds reproducible, with good progress (tock/tock#1666). In particular:

  • pinning a version of the Rust compiler,
  • using --remap-path-prefix,
  • using a Cargo workspace,
  • using cargo rustc to avoid passing custom linker arguments (that include paths on the filesystem) to the dependencies.

This allows reproducibility of the builds on various Linux machines.

However, the builds are different on MacOS, as evidenced by CI on a GitHub workflow (google/OpenSK#94 (comment)).

In particular, the issue seems to stem from a different -C metadata= (and -C extra-filename=) passed to rustc (while the steps that I mentioned above make sure that the same metadata hash is passed across Linux machines for each crate in the project).

These are built with the --verbose parameter passed to cargo, and an example rustc invocation is the following (tock_cells crate of the Tock project). Do you have any idea of which invocation parameter could cause the metadata to be different?

  • On Linux (https://github.com/google/OpenSK/pull/94/checks?check_run_id=602439620): rustc --crate-name tock_cells libraries/tock-cells/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=z -C panic=abort -C debuginfo=2 -C metadata=92487154152022d3 -C extra-filename=-92487154152022d3 --out-dir /home/runner/work/OpenSK/OpenSK/third_party/tock/target/thumbv7em-none-eabi/release/deps --target thumbv7em-none-eabi -L dependency=/home/runner/work/OpenSK/OpenSK/third_party/tock/target/thumbv7em-none-eabi/release/deps -L dependency=/home/runner/work/OpenSK/OpenSK/third_party/tock/target/release/deps -C link-arg=-Tlayout.ld -C linker=rust-lld -C linker-flavor=ld.lld -C relocation-model=dynamic-no-pic -C link-arg=-zmax-page-size=512 -C link-arg=-icf=all --remap-path-prefix=/home/runner/work/OpenSK/OpenSK/third_party/tock/= -D warnings
  • On OSX (https://github.com/google/OpenSK/pull/94/checks?check_run_id=602439631): rustc --crate-name tock_cells libraries/tock-cells/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts --crate-type lib --emit=dep-info,metadata,link -C opt-level=z -C panic=abort -C debuginfo=2 -C metadata=9fc982d890c0358d -C extra-filename=-9fc982d890c0358d --out-dir /Users/runner/runners/2.169.0/work/OpenSK/OpenSK/third_party/tock/target/thumbv7em-none-eabi/release/deps --target thumbv7em-none-eabi -L dependency=/Users/runner/runners/2.169.0/work/OpenSK/OpenSK/third_party/tock/target/thumbv7em-none-eabi/release/deps -L dependency=/Users/runner/runners/2.169.0/work/OpenSK/OpenSK/third_party/tock/target/release/deps -C link-arg=-Tlayout.ld -C linker=rust-lld -C linker-flavor=ld.lld -C relocation-model=dynamic-no-pic -C link-arg=-zmax-page-size=512 -C link-arg=-icf=all --remap-path-prefix=/Users/runner/runners/2.169.0/work/OpenSK/OpenSK/third_party/tock/= -D warnings

This could be relevant to #34902, although this issue is more specific.

@jonas-schievink
Copy link
Contributor

This might be (but doesn't have to be) a Cargo bug, since it generates that hash.

@jonas-schievink jonas-schievink added A-reproducibility Area: Reproducible / deterministic builds C-bug Category: This is a bug. T-cargo Relevant to the cargo team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Apr 20, 2020
@gendx
Copy link
Author

gendx commented Apr 21, 2020

This might be (but doesn't have to be) a Cargo bug, since it generates that hash.

Makes sense. I've filed an issue on Cargo as well to see if the problem is there.

@gendx
Copy link
Author

gendx commented Apr 21, 2020

Closing in favor of rust-lang/cargo#8140. Let's see if there is any issue on the rustc side once the cargo issue is fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-reproducibility Area: Reproducible / deterministic builds C-bug Category: This is a bug. T-cargo Relevant to the cargo team, which will review and decide on the PR/issue. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants