Export ZERO_AR_DATE for macos linker invocations

[alexcrichton]

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 #47086
Closes #66568

[rust-highfive]

r? @eddyb

(rust_highfive has picked a reviewer for you, use r? to override)

[eddyb]

I'm not a macOS person but the explanation looks reasonable. Sorry for the delay!

@bors r+

[bors]

📌 Commit d60ef36c876284a6eedd90df394ec79b63b6a9e2 has been approved by eddyb

[bors]

⌛ Testing commit d60ef36c876284a6eedd90df394ec79b63b6a9e2 with merge 7bec456cd7c73c68787f244d5f1df6084ae20bf7...

[bors]

💔 Test failed - checks-azure

[alexcrichton]

Looks like cp -r doesn't follow symlinks on Linux but does on macOS, causing a failure. Looks like cp -R doesn't follow symlinks on both!

@bors: r=eddyb

[bors]

📌 Commit afd88f2 has been approved by eddyb

[bors]

⌛ Testing commit afd88f2 with merge 5239f5c...

[bors]

☀️ Test successful - checks-azure
Approved by: eddyb
Pushing 5239f5c to master...

[pnkfelix]

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 rustc with debug=true (just like #66568 and I think #47086), but this time on a Linux host.

So I am wondering: What's the downside of exporting this environment variable on all platforms? Or, all unix platforms at least?

[eddyb]

@pnkfelix I can't find anything from a quick googling that suggests this applies to anything other than Apple's own ld64 linker (or lld's Mach-O mode, which emulates it).

[pnkfelix]

Hmm. So either Linux machines do not run into this embedding of an unstable mtime value (and my local test is failing for some other reason), or Linux machines do run into it, but the workaround deployed here does not apply.

Does that sound correct?

[eddyb]

Does that sound correct?

Yes, that matches my understanding. I remember recently running into something with tar, where the defaults are atrocious¹, but I thought ar wasn't subject to the same issues.

^{1. --sort=name --mtime=1970-01-01Z --numeric-owner --owner=0 --group=0 are the flags needed by tar - note the Z, without it, it depends on your timezone, that was "fun" to debug. and --mtime=0 means "start of today" or some useless thing like that, so you have to put in the UNIX epoch by hand}