build: stop exporting GOOS=linux globally#5714
Merged
rene merged 1 commit intolf-edge:masterfrom Mar 31, 2026
Merged
Conversation
7860b87 to
5c6dd7a
Compare
The top-level Makefile hardcodes GOOS=linux and exports it to all sub-makes and child processes. This is correct for EVE packages (they run on Linux), but breaks host tools on macOS: the exported value overrides each tool's own host-OS detection, producing Linux binaries that cannot execute on the build host. The immediate symptom is linuxkit (built from source via mk/linuxkit.mk) getting GOOS=linux instead of GOOS=darwin, but the same bug is latent in dockerfile-from-checker and GOSOURCES. Fix: - Remove the global GOOS=linux assignment (line 337) and drop GOOS and GOARCH from the export list. - In DOCKER_GO, hardcode -e GOOS=linux -e GOARCH=$(ZARCH) so the Linux container always gets the correct values explicitly. - Remove the now-redundant GOOS=$(LOCAL_GOOS) overrides from get-deps and compare-sbom-sources — with no global export, Go defaults to the host OS automatically. Signed-off-by: Mikhail Malyshev <mike.malyshev@gmail.com>
5c6dd7a to
a364d1b
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #5714 +/- ##
==========================================
+ Coverage 19.52% 29.12% +9.59%
==========================================
Files 19 10 -9
Lines 3021 1133 -1888
==========================================
- Hits 590 330 -260
+ Misses 2310 768 -1542
+ Partials 121 35 -86 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
This was referenced Mar 31, 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
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.
Description
The top-level Makefile hardcodes
GOOS=linuxand exports it to all sub-makes and child processes. This is correct for EVE packages (they run on Linux), but breaks host tools on macOS: the exported value overrides each tool's own host-OS detection, producing Linux binaries that cannot execute on the build host.The immediate symptom is linuxkit (built from source via
mk/linuxkit.mk) gettingGOOS=linuxinstead ofGOOS=darwin, but the same bug is latent indockerfile-from-checkerandGOSOURCES.Changes:
GOOS=linuxassignment and dropGOOS/GOARCHfrom theexport list.
DOCKER_GO, hardcode-e GOOS=linux -e GOARCH=$(ZARCH)so the Linux container always gets the correct values explicitly.GOOS=$(LOCAL_GOOS)overrides fromget-depsandcompare-sbom-sources— with no global export, Go defaults to the host OS.How to test and validate this PR
make linuxkit— should build a linux-amd64 binary (no behavior change)make linuxkit— should build a darwin binary (was broken before)make linuxkit LINUXKIT_GIT_URL=""— should downloadlinuxkit-darwin-amd64make rootfs HV=kvm ZARCH=amd64— pillar and all EVE packages still build with GOOS=linuxChangelog notes
No user-facing changes. Build system fix for macOS developers.
PR Backports
Checklist
I've provided a proper description
I've added the proper documentation
I've tested my PR on amd64 device
I've tested my PR on arm64 device
I've written the test verification instructions
I've set the proper labels to this PR
I've checked the boxes above, or I've provided a good reason why I didn't
check them.