The two linux archives under lib/ are built for x86_64-unknown-linux-gnu and aarch64-unknown-linux-gnu. On a musl distribution, Alpine being the one most people meet, the default linking mode fails at link time with whatever the linker says about a glibc archive, which is not a message that tells anybody what to do next.
The README now says the archives are glibc and points at -tags zu_system for that case. That is the truth but it is not a fix, because it asks somebody who chose Alpine to get a Rust toolchain and build the engine themselves, which is the exact thing the vendored archives exist to avoid.
Alpine is not a niche here. It is the default base image in a large fraction of the container ecosystem, and a Go binary against a static archive is precisely the shape people pick Alpine for.
What it needs:
x86_64-unknown-linux-musl and aarch64-unknown-linux-musl archives, as two more modules under lib/, built by the Libraries workflow the same way the others are- build tags that pick between gnu and musl, which Go does not have a constraint for, so it has to come from a tag the user sets or from a cgo-time probe
- a row in the Install workflow on
golang:1.26-alpine, which is the only thing that would keep it working
The tag selection is the part with a design decision in it. Go has no build constraint for the libc, so either the user writes -tags zu_musl and the failure mode for forgetting is the link error we have today, or the choice is made in cgo preamble from something the C compiler knows, which works but puts the decision somewhere a reader of the Go files cannot see.
Until then the Install workflow deliberately has no alpine row, because a row that is known to fail is not a gate.
The two linux archives under
lib/are built forx86_64-unknown-linux-gnuandaarch64-unknown-linux-gnu. On a musl distribution, Alpine being the one most people meet, the default linking mode fails at link time with whatever the linker says about a glibc archive, which is not a message that tells anybody what to do next.The README now says the archives are glibc and points at
-tags zu_systemfor that case. That is the truth but it is not a fix, because it asks somebody who chose Alpine to get a Rust toolchain and build the engine themselves, which is the exact thing the vendored archives exist to avoid.Alpine is not a niche here. It is the default base image in a large fraction of the container ecosystem, and a Go binary against a static archive is precisely the shape people pick Alpine for.
What it needs:
x86_64-unknown-linux-muslandaarch64-unknown-linux-muslarchives, as two more modules underlib/, built by the Libraries workflow the same way the others aregolang:1.26-alpine, which is the only thing that would keep it workingThe tag selection is the part with a design decision in it. Go has no build constraint for the libc, so either the user writes
-tags zu_musland the failure mode for forgetting is the link error we have today, or the choice is made in cgo preamble from something the C compiler knows, which works but puts the decision somewhere a reader of the Go files cannot see.Until then the Install workflow deliberately has no alpine row, because a row that is known to fail is not a gate.