fix(build): derive xgo image tag from GO_VERSION - #424
Merged
Conversation
The Go version was pinned in three places and #422 updated only two: native/go.mod, GO_VERSION in the workflows, and the hardcoded xgo image tag here (left at go-1.25.10). Once go.mod requires go >= 1.26.0, the toolchain inside the go-1.25.10 container auto-downloads Go 1.26.0 and runs its linker against that image's older GNU binutils, which cannot parse the .def file Go 1.26 emits. The Windows DLL then fails to link and the enforcer reports the missing file as the symptom. Deriving the tag from GO_VERSION removes the drift: CI already exports it, and make's `?=` prefers the environment value. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Marc Nuri <marc@marcnuri.com>
There was a problem hiding this comment.
🟢 Approval recommended
The change is small, self-contained in the Makefile, and correctly ties the xgo image tag to the already CI-exported GO_VERSION to eliminate a known drift failure mode.
Pull request overview
Aligns the xgo Docker image selection with the CI-pinned Go toolchain version to prevent Makefile/CI drift that can break cross-compilation (notably the Windows DLL build) when native/go.mod requires a newer Go than the container ships.
Changes:
- Introduces
GO_VERSION ?= 1.26.7as a Makefile default that is overridden by CI’s exportedGO_VERSION. - Derives
XGO_IMAGEfromGO_VERSIONand switches the cross-platform build to use-image $(XGO_IMAGE).
File summaries
| File | Description |
|---|---|
| Makefile | Adds GO_VERSION/XGO_IMAGE variables and uses them for xgo cross-platform builds to keep CI and Makefile in sync. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
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
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.
Problem
The Linux job on #419 fails while cross-compiling the Windows DLL:
helm-windows-4.0-amd64.dllis therefore never produced, and the build laterstops on:
The enforcer error is the symptom that gets reported, not the cause.
Root cause
The Go version is pinned in three places, and only two were updated when
GO_VERSIONmoved to 1.26.7:native/go.modgo 1.26.0(raised by #419)GO_VERSIONin.github/workflows/*.yml1.26.7Makefilego-1.25.10Once
go.modrequires>= 1.26.0, the Go toolchain inside thego-1.25.10container auto-downloads Go 1.26.0 and links with it — against the mingw-w64
binutils that image ships. That older GNU
ldcannot parse the.deffile Go1.26 emits.
This is why
mainstayed green: itsgo.modstill says1.25.10, so thecontainer never downloads a different toolchain and the mismatch never appears.
Fix
Derive the image tag from
GO_VERSION. The workflows already export it, andmake's
?=prefers an environment value over the default, so CI and theMakefile can no longer drift apart. Local builds default to 1.26.7.
Verification
Ran the exact failing scenario inside
ghcr.io/techknowlogick/xgo:go-1.26.7:go1.26.7and LLD 21.1.8 asx86_64-w64-mingw32-ld(not GNUld)-buildmode=c-sharedwindows/amd64build links successfullyConfirmed with
go.modat bothgo 1.26.0(as on #419) andgo 1.25.10(as onmain today), so this is safe to land ahead of #419.
Unblocks #419, the last remaining dependabot PR.