[draft] feat(go-build): explore TinyGo for wasm build targets#818
Draft
electricjesus wants to merge 6 commits intoprojectcalico:masterfrom
Draft
[draft] feat(go-build): explore TinyGo for wasm build targets#818electricjesus wants to merge 6 commits intoprojectcalico:masterfrom
electricjesus wants to merge 6 commits intoprojectcalico:masterfrom
Conversation
Adds amd64 + arm64 sha256 entries. Consumed by the TinyGo install block added in a follow-up commit. ppc64le/s390x not listed — upstream TinyGo does not ship those archs.
Reads version + per-arch sha256 from versions.yaml, downloads upstream tarball, verifies checksum, extracts to /usr/local. ppc64le/s390x skipped — upstream does not ship those archs. PATH unconditionally extended; tinygo absent on excluded archs fails with command-not-found which is the correct behavior.
Mirrors the existing felix-UT real-consumer smoke pattern using the embedded fixture under images/calico-go-build/test/wasm-smoke/. Compiles a tiny wasm with the exact flag set coraza-wasm uses, then verifies the binary is well-formed. amd64+arm64 only; ppc64le/s390x exercise the skip path.
… stage-1 PATH TinyGo 0.37+ release binaries link against GCC 12+ libstdc++ and require GLIBCXX_3.4.30. AlmaLinux 9's default libstdc++ comes from GCC 11 and only provides up to GLIBCXX_3.4.29, so tinygo crashed at runtime with 'libstdc++.so.6: version GLIBCXX_3.4.30 not found'. Install gcc-toolset-13-libstdc++-devel from CRB and add its lib path to ld.so.conf.d so the dynamic linker resolves newer GLIBCXX. Forward-compat ABI keeps older binaries working. Also fix the stage-1 PATH — the ENV PATH directive was in the builder stage, which the squash 'FROM scratch + COPY --from=builder /' does not carry over. Append /usr/local/tinygo/bin to the stage-1 ENV PATH so tinygo is discoverable in the final image. Both fixes are required to make 'tinygo version' work in the final calico/go-build image. TODO: drop the gcc-toolset-13 install once go-build base moves to AlmaLinux 10 (ships GCC 14 + GLIBCXX_3.4.32+ natively).
TinyGo 0.37+ release binaries link against GCC 12+ libstdc++ and require GLIBCXX_3.4.30 at runtime. AlmaLinux 9 ABI-freezes the system libstdc++ at GCC 11 (max GLIBCXX_3.4.29) and does not ship a newer libstdc++.so.6 runtime in any official rpm — gcc-toolset-N packages provide dev symlinks and static libs only, not the .so.6 runtime needed for dynamically linked binaries. 0.34.0 is the last upstream TinyGo release that works against AlmaLinux 9's default libstdc++ (max GLIBCXX_3.4.26 needed). Coraza-proxy-wasm upstream pins this same version, so the calico plugin lift is unaffected. Bump path: AlmaLinux 10 base ships GCC 14 (GLIBCXX_3.4.32+) and unblocks newer TinyGo natively. Track as a follow-up when go-build moves to AL10. Reverts the gcc-toolset-13-libstdc++-devel workaround attempted in the previous commit — that package only ships dev/static libs, not the runtime .so.6 we needed.
TinyGo 0.37+ release binaries need GLIBCXX_3.4.30+ at runtime. AlmaLinux 9 ABI-freezes the system libstdc++ at GCC 11 (max GLIBCXX_3.4.29) and does not ship a newer libstdc++.so.6 runtime in any official rpm — gcc-toolset-N packages contain dev/static libs only. Pinning to TinyGo 0.34.0 (last AL9-compatible version) was the previous approach but TinyGo 0.34.0 caps host Go at 1.23 while calico/go-build ships Go 1.26.2 — the older TinyGo refuses to operate against the newer Go. Resolution: bundle libstdc++.so.6.0.33 from Debian trixie's gcc-14 package (libstdc++6_14.2.0-19). Forward-compat ABI means the newer .so transparently satisfies older GLIBCXX consumers that were already linking against the AL9 system libstdc++. Sha256-verified at build time. Pinned in versions.yaml under tinygo.libstdcpp.deb_version and per-arch sha256 entries. Bump path: when go-build base moves to AlmaLinux 10 (ships GCC 14 natively, GLIBCXX_3.4.32+), drop this Debian-bundled libstdc++.
Member
Author
|
@hjiawei - opening this as a draft RFC because I hit a wall on AlmaLinux 9. I tried 4 things, all failed. The PR body has the short version. Three options at the bottom. Want your input before I pick one. No rush .. tag me back when you have time. Thanks! |
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.
Status: DRAFT / RFC - asking for your advice
This PR does not work yet. I'm posting it because I'm stuck and I want your input before I keep trying.
What I want to do
Add TinyGo to
calico/go-build. Thencalico-private/gateway/coraza-wasm/can stop using the upstreamtinygo/tinygo:0.34.0image and use our toolchain image instead.Full design + plan (in another repo):
docs/planning/2026-04-30-tinygo-toolchain-migration-design.md- see §13 for the long version of what's below.docs/planning/2026-04-30-tinygo-toolchain-migration-plan.md.What I tried (4 things, all failed)
The 6 commits in this PR walk through each attempt. Each commit message has the full detail.
Install TinyGo 0.41 from upstream tarball. Failed: TinyGo 0.41 needs
GLIBCXX_3.4.30. AlmaLinux 9 only has up toGLIBCXX_3.4.29(it ships GCC 11).Install
gcc-toolset-13-libstdc++-develfrom CRB. Failed: that rpm only has dev/static files. Nolibstdc++.so.6runtime is shipped in any gcc-toolset rpm. I checked all of them.Pin TinyGo to 0.34 (last AL9-compatible version). Failed: TinyGo 0.34 only supports Go up to 1.23.
calico/go-buildhas Go 1.26. TinyGo refuses to run.Bundle libstdc++ from Debian trixie. Failed: the Debian libstdc++ needs glibc 2.36+. AlmaLinux 9 has glibc 2.34. Can't fix glibc without replacing the OS base.
CI on this PR fails at the
su-execbuild step (commitc669709). That's the wall.Three options I see
Move
calico/go-buildto AlmaLinux 10. AL10 has glibc 2.39 + GCC 14, TinyGo 0.41 just works, no workarounds. Big change for the whole team.Two variants: AL9 and AL10. Same pattern
calico-basealready uses (UBI_VERSIONS ?= ubi9 ubi10). The plugin uses ubi10. Other components stay on ubi9 until they are ready. Unblocks the plugin without forcing everyone.New image:
calico/wasm-buildon AL10. Just for wasm. Small change. But it adds one more image.What I want to ask you
dnf moduletrick to get newer libstdc++ on AL9?tinygo/tinygo:0.34.0for now - is that OK with you while we figure this out?Thanks!