cmd/go: macOS plugin builds are not reproducible #58557
Assignees
Labels
FrozenDueToAge
GoCommand
cmd/go
NeedsFix
The path to resolution is known, but the work has not been done.
OS-Darwin
Milestone
Comments
gopherbot
added
the
compiler/runtime
|
Temporary directory is in |
misha-ridge
changed the title
misha-ridge
changed the title
|
It looks like there is an existing case here that attempts to mitigate |
bcmills
added
the
NeedsFix
mknyszek
removed
the
compiler/runtime
|
Change https://go.dev/cl/477296 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Mar 17, 2023
There is already a case that when buildmode=shared passes only the basename of the -o argument to the link command to the linker (and runs in the directory of that argument) to avoid having that (temporary) directory of the file be included in the LC_ID_DYLIB load command. Extend the case to buildmode=plugin, because the same thing can happen there. This can only happen on darwin: the -o command can be embedded into Mach-O and PE binaries, but plugin isn't supported on Windows. For #58557 Change-Id: I7a4a5627148e77c6906ac4583af3d9f053d5b249 Reviewed-on: https://go-review.googlesource.com/c/go/+/477296 Run-TryBot: Michael Matloob <matloob@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Matloob <matloob@golang.org>
|
Change https://go.dev/cl/478196 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
Mar 21, 2023
On Linux, for a shared object, at least with the Gold linker, the output file path is recorded in the .gnu.version_d section. When the output file path is in a temporary directory, it causes nondeterministic build. This is similar to #58557, but for Linux with the Gold linker. Apply the same workaround as in CL 477296. Should fix the linux-arm64-longtest builder. Change-Id: Ic703bff32c1bcc40054b89be696e04280855e876 Reviewed-on: https://go-review.googlesource.com/c/go/+/478196 Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com>
|
Change https://go.dev/cl/494577 mentions this issue: |
gopherbot
pushed a commit
that referenced
this issue
May 12, 2023
This avoids printing verbose binary data and making bell sounds when the test fails. The binary data can be inspected via other means if needed. For #58557. Change-Id: Ia1c4f2c6b9ff2cf6f97611cf335b978fc7bb201f Reviewed-on: https://go-review.googlesource.com/c/go/+/494577 Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Bryan Mills <bcmills@google.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version)?Tested with Go 1.19 and Go 1.20
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env)?go envOutputWhat did you do?
I have created a package with single
mainfunction and built it on Mac twice as a plugin:The resulting binaries differ.
Reproducer is at https://github.com/misha-ridge/test-plugin-build
What did you expect to see?
I expected the binaries to be identical.
What did you see instead?
Plugin embeds a temporary directory path, plus some other differences that might be related to it:
The text was updated successfully, but these errors were encountered: