-
-
Notifications
You must be signed in to change notification settings - Fork 678
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
Full stdlib file paths in binary #969
Comments
Set GOROOT_FINAL to a constant string ('GOROOT') when linking. Normally, the actual path to GOROOT is set in linked binaries, which results in non-reproducible builds. GOROOT_FINAL provides a constant replacement. Also, added a test for common reproducibility problems. Fixes bazel-contrib#969
Set GOROOT_FINAL to a constant string ('GOROOT') when linking. Normally, the actual path to GOROOT is set in linked binaries, which results in non-reproducible builds. GOROOT_FINAL provides a constant replacement. Also, added a test for common reproducibility problems. Fixes bazel-contrib#969
Set GOROOT_FINAL to a constant string ('GOROOT') when linking. Normally, the actual path to GOROOT is set in linked binaries, which results in non-reproducible builds. GOROOT_FINAL provides a constant replacement. Also, added a test for common reproducibility problems. Fixes #969
FYI I was debugging why our test wrapper that @linzhp posted in #2370 stopped setting up go environment variables correctly in Go 1.23rc1, and realized that GOROOT was no longer set to "GOROOT" within our tests, instead being set to an actual sdk within bazel sandbox. Seems like golang/go#62047 may have caused this issue to come back. Not sure if there's a good replacement solution or not yet cc: @jayconrod |
Due to golang/go#62047, Go 1.23 won't support `GOROOT_FINAL`. This means that bazel-contrib#971 will no longer fix bazel-contrib#969, meaning linked binaries will contain full GOROOT paths, making them non-reproducible. Instead of using `GOROOT_FINAL`, this change sets `GOROOT` when invoking the linker, which will cause the linker to continue to write `GOROOT` into the binary, keeping builds consistent. This works on Go 1.23rc1 as well. I'm not a rules_go expert and I'm not married to this particular solution, I just wanted to bring attention to the issue. If there's a clever way we can set `-trimpath` when invoking the compiler, that might be better - but we already use that flag to trim off the bazel sandbox I believe.
* Clear GOROOT when linking Due to golang/go#62047, Go 1.23 won't support `GOROOT_FINAL`. This means that #971 will no longer fix #969, meaning linked binaries will contain full GOROOT paths, making them non-reproducible. Instead of using `GOROOT_FINAL`, this change sets `GOROOT` when invoking the linker, which will cause the linker to continue to write `GOROOT` into the binary, keeping builds consistent. This works on Go 1.23rc1 as well. I'm not a rules_go expert and I'm not married to this particular solution, I just wanted to bring attention to the issue. If there's a clever way we can set `-trimpath` when invoking the compiler, that might be better - but we already use that flag to trim off the bazel sandbox I believe. * switch based on runtime.Version
Seems like paths to standard library packages are put into the binary. That means builds are not reproducible, right?
The text was updated successfully, but these errors were encountered: