x/build: aix-ppc64 builder has non-reproducible cgo builds #56896
Comments
|
Change https://go.dev/cl/452680 mentions this issue: |
cherrymui
added
the
NeedsInvestigation
The gcc toolchain on the aix-ppc64 builder apparently does not achieve reproducible builds for packages that use cgo, which causes the binaries in cmd that use package "net" (cmd/go, cmd/pprof, and cmd/trace) to appear stale whenever the Go build cache is cleared. For now, we work around the staleness by rebuilding std and simply not checking whether cmd is stale. For #56896. Updates #47257. Change-Id: I15f86e72dee53904b881710d5d5d613872361510 Reviewed-on: https://go-review.googlesource.com/c/go/+/452680 Run-TryBot: Bryan Mills <bcmills@google.com> Reviewed-by: Ayappan Perumal <ayappanec@gmail.com> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
|
Change https://go.dev/cl/452775 mentions this issue: |
bcmills
changed the title
|
The builder is once again passing (by skipping the staleness checks), so I've retitled the issue to reflect the underlying reproducibility problem that remains. |
|
@ayappanec Would you look into this? |
|
Yes, Looking into it |
|
For what it's worth, CL 454836 is going to start building cmd without cgo, which will eliminate this as a concern even if it doesn't fix the underlying problem. |
|
@cherrymui identified a source of nondeterminism in #57035. Does that explain this platform too? (Does patching in https://go.dev/cl/454838 fix the symptoms reported here?) |
|
GCC in AIX uses AIX native linker and assembler. I see the assembler always creates non-deterministic object files in AIX. So probably this looks like a limitation with AIX build |
|
@ayappanec Can you build with https://go-review.googlesource.com/c/go/+/454838 and see if that resolves the nondeterminism? |
|
I tried. It doesn't... |
Since packages in "std" no longer have install targets, checking them for staleness is somewhat meaningless: if they are not cached they will be rebuilt anyway, and without installed archives against which we can compare them the staleness check will not detect builder skew. It would still be meaningful to check "cmd" for staleness, but (especially on sharded VM-based builders) that is a fairly expensive operation relative to its benefit. If we are really interested in detecting builder skew and/or build reproducibility, we could instead add a "misc" test (similar to "misc/reboot", or perhaps even a part of that test) that verifies that bootstrapped binaries are reproducible. For #57734. Updates #47257. Updates #56896. Change-Id: I8683ee81aefe8fb59cce9484453df9729bdc587c Reviewed-on: https://go-review.googlesource.com/c/go/+/452775 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Austin Clements <austin@google.com>
Since packages in "std" no longer have install targets, checking them for staleness is somewhat meaningless: if they are not cached they will be rebuilt anyway, and without installed archives against which we can compare them the staleness check will not detect builder skew. It would still be meaningful to check "cmd" for staleness, but (especially on sharded VM-based builders) that is a fairly expensive operation relative to its benefit. If we are really interested in detecting builder skew and/or build reproducibility, we could instead add a "misc" test (similar to "misc/reboot", or perhaps even a part of that test) that verifies that bootstrapped binaries are reproducible. For golang#57734. Updates golang#47257. Updates golang#56896. Change-Id: I8683ee81aefe8fb59cce9484453df9729bdc587c Reviewed-on: https://go-review.googlesource.com/c/go/+/452775 Run-TryBot: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Bryan Mills <bcmills@google.com> Reviewed-by: Austin Clements <austin@google.com>
What version of Go are you using (
go version)?What did you do?
Ran
go list -export -json=BuildID runtime/cgobefore and after clearing the Go build cache.Note that the first part of the build ID (describing the inputs to the build) is identical; however, the second part (describing the output of the compiler) is not.
What did you expect to see?
Because the
runtime/cgopackage is within GOROOT, its build should always be reproducible (see #50183), and so each fresh rebuild of the package should result in the sameBuildID, and any package in GOROOT that uses it (such asnet) should also have a reproducible build.Setting
CGO_ENABLED=0does result in a reproducible build for thenetpackage on theaix-ppc64builder:And on
linux/amd64(and presumably other platforms), we do see reproducible builds forruntime/cgoeven with cgo enabled:What did you see instead?
With cgo enabled, the
BuildIDfor theruntime/cgoandnetpackages on theaix-ppc64builder differ each time the package is rebuilt from a clean cache.(attn @golang/aix; CC @ianlancetaylor in case he has any tips on cgo reproducibility)
The text was updated successfully, but these errors were encountered: