Export ZERO_AR_DATE for macos linker invocations#71931
Conversation
|
r? @eddyb (rust_highfive has picked a reviewer for you, use r? to override) |
|
I'm not a macOS person but the explanation looks reasonable. Sorry for the delay! @bors r+ |
|
📌 Commit d60ef36c876284a6eedd90df394ec79b63b6a9e2 has been approved by |
|
⌛ Testing commit d60ef36c876284a6eedd90df394ec79b63b6a9e2 with merge 7bec456cd7c73c68787f244d5f1df6084ae20bf7... |
|
💔 Test failed - checks-azure |
This commit attempts to improve reproducibility of builds on macOS by exporting the `ZERO_AR_DATE=1` environment variable for all invocations of the linker. While it looks like this env var is targeted at just the `ar` command (which does actually read this) it appears that recent-ish versions of the linker *also* read this environment variable. This env var forces the linker to set a deterministic zero value for the mtime in the N_OSO field of the object file. Currently it's believe that older versions of the linker will simply ignore this env var, while newer versions will read it and produce a deterministic output for compilations with debuginfo. Closes rust-lang#47086 Closes rust-lang#66568
d60ef36 to
afd88f2
Compare
|
Looks like @bors: r=eddyb |
|
📌 Commit afd88f2 has been approved by |
|
☀️ Test successful - checks-azure |
|
Hey @alexcrichton , why did you restrict this to just Mac OS? I am seeing the reproducible-build-2 test fail once again on a build of So I am wondering: What's the downside of exporting this environment variable on all platforms? Or, all unix platforms at least? |
|
@pnkfelix I can't find anything from a quick googling that suggests this applies to anything other than Apple's own |
|
Hmm. So either Linux machines do not run into this embedding of an unstable Does that sound correct? |
Yes, that matches my understanding. I remember recently running into something with 1. |
This commit attempts to improve reproducibility of builds on macOS by
exporting the
ZERO_AR_DATE=1environment variable for all invocationsof the linker. While it looks like this env var is targeted at just the
arcommand (which does actually read this) it appears that recent-ishversions of the linker also read this environment variable. This
env var forces the linker to set a deterministic zero value for the
mtime in the N_OSO field of the object file.
Currently it's believe that older versions of the linker will simply
ignore this env var, while newer versions will read it and produce a
deterministic output for compilations with debuginfo.
Closes #47086
Closes #66568