Upgrade to Go v1.26 and build separate Windows resource files on 386 and amd64 platforms - #6220
Merged
Merged
Conversation
Go version 1.26 has been released, and because we aim to build and test Git LFS against only supported versions of Go, we upgrade our GitHub Actions CI workflows to test against Go versions 1.26 and 1.25. This resolves a problem now seen in our "Build with specific Go" CI job, where we install the latest version of the "goimports" package and it fails because the "x/tools" module requires Go v1.25 as of commit golang/tools@f644bf7, and we are still using Go v1.24 for that CI job.
In commit golang/go@594deca a long-standing Go linker issue was resolved so that relocations on the 386 and amd64 platforms are now handled appropriately and no longer accidentally conflated. This change was then included in the Go v1.26 release. However, one consequence of this bug fix is that users of the "goversioninfo" command provided by the "github.com/josephspurrier/goversioninfo" package must now disambiguate their Windows builds on the two platforms, because that command defaults to generating resource files for the 386 platform. These "resource.syso" files would previously suffice for the amd64 platform as well because the Go linker would incorrectly allow them to be embedded in the binaries it produced. See, for reference: golang/go#77783 (comment) https://go-review.googlesource.com/c/go/+/672155 In a prior commit in this PR we upgraded our CI and release GitHub Actions workflows to use Go v1.26, and as a result, our Windows jobs will not succeed unless we also ensure that we build separate resource files for the 386 and amd64 platforms. We therefore replace our common "git-lfs_windows.go" source file with distinct "git-lfs_windows_386.go" and "git-lfs_windows_amd64.go" files. Each of these specifies a single Go architecture build tag, either "386" or "amd64", and in the latter case we pass the "-64=true" option to the "goversioninfo" command, while in the former case we defer to the command's default 32-bit setting.
chrisd8088
force-pushed
the
upgrade-go-1-26
branch
from
March 16, 2026 16:49
ce41a56 to
d12ad86
Compare
larsxschneider
approved these changes
Mar 16, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Go version 1.26 has been released, and because we aim to build and test Git LFS against only supported versions of Go, we upgrade our GitHub Actions CI workflows to test against Go versions 1.26 and 1.25.
This resolves a problem now seen in our
Build with specific GoCI job, where we install the latest version of thegoimportspackage and it fails because thex/toolsmodule requires Go v1.25 as of commit golang/tools@f644bf7, and we are still using Go v1.24 for that CI job.After this PR is merged, we will revise the required set of jobs in our CI test suite, and also upgrade the version of Go used in the scripts and Dockerfiles in our
github/build-dockersproject.We also revise our Windows builds so that we create separate
resource.sysofiles on the386andamd64platforms, in order to avoid anunknown relocation type 7error which would otherwise now occur in our Windows CI jobs.In commit golang/go@594deca a long-standing Go linker issue was resolved so that relocations on the
386andamd64platforms are now handled appropriately and no longer accidentally conflated. This change was then included in the Go v1.26 release.One consequence of this bug fix is that users of the
goversioninfocommand provided by thegithub.com/josephspurrier/goversioninfopackage must now disambiguate their Windows builds on the two platforms, because that command defaults to generating resource files for the386platform. Theseresource.sysofiles would previously suffice for theamd64platform as well because the Go linker would incorrectly allow them to be embedded in the binaries it produced. For reference, see golang/go#77783 (comment) and CL 672155.We therefore replace our common
git-lfs_windows.gosource file with distinctgit-lfs_windows_386.goandgit-lfs_windows_amd64.gofiles. Each of these specifies a single Go architecture build tag, either386oramd64, and in the latter case we pass the-64=trueoption to the "goversioninfocommand, while in the former case we defer to the command's default 32-bit setting.