Build binary with newer Go Versions? #1454

Activity

1. laizy commented on Apr 10, 2025

   

   laizy

   on Apr 10, 2025

   Contributor

   More actions

   We have already built it with Go v1.22 in github action:
   

   ontology/.github/workflows/go.yml

   Line 19 in d45fdd7

   go-version: 1.22.5
2. SafraNako commented on Sep 8, 2026

   

   SafraNako

   on Sep 8, 2026

   More actions

   I dug into this. Reproduced the exact error on current master (go.mod now
   says go 1.23.0, built with Go 1.27.0):

   $ GOOS=linux GOARCH=amd64 go build -o ontology-linux-amd64 main.go
   smartcontract/service/wasmvm/utils.go:113:11: undefined: WasmjitValidate
   smartcontract/service/wasmvm/wasm_service.go:155:17: undefined: invokeJit
   

   Root cause: smartcontract/service/wasmvm/wasmjit_runtime.go uses cgo
   (import "C"), and it's the only file that defines WasmjitValidate /
   invokeJit — no build tags, no fallback stub. Go disables cgo by default
   whenever it cross-compiles (GOOS/GOARCH differ from the host), unless
   CGO_ENABLED=1 is set explicitly with a working cross C toolchain for the
   target. With cgo off, that file is silently dropped from the build, so
   everything that calls into it becomes "undefined".

   I confirmed this is the mechanism, not a Go-version regression, by forcing it:

   $ CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -o ontology-linux-amd64 main.go
   # runtime/cgo
   gcc_clearenv.c:16:2: error: implicit declaration of function 'clearenv'
   linux_syscall.c:67:13: error: implicit declaration of function 'setresgid'
   ...
   

   That's macOS's C toolchain trying to compile Linux-only libc calls — expected,
   since there's no Linux cgo cross-toolchain configured. It shows the failure is
   specifically "cross-compiling cgo code without a cross C toolchain for the
   target," which is host-OS-dependent, not Go-version-dependent.

   This matches @laizy's point above: make ontology-linux (or a plain
   GOOS=linux go build) works fine in CI because ubuntu-latest runners build
   natively for linux/amd64 — GOOS/GOARCH match the host, so cgo stays on by
   default and the system C compiler is a real Linux one.

   So: building on Linux (bare metal, a VM, or a linux/amd64 Docker container)
   works regardless of Go version. Cross-compiling the Linux binary from a
   different host OS (e.g. macOS, as in the original report) needs a proper
   Linux cgo cross-toolchain configured (CC=<target-triple>-gcc etc.) — that's
   a wasmjit/cgo limitation of this build target, independent of which Go
   version is installed.
3. SafraNako commented on Sep 9, 2026

   

   SafraNako

   on Sep 9, 2026

   More actions

   Opened a small follow-up documenting this in the Makefile so the next person doesn't have to re-diagnose it: #1462