[jgowdy]

Here are some citations since people seem to be just downvoting because they don't like the message:

Go requiring non-ELF standard parameters for initialization of supposedly "C ABI" libraries, open since 2015.

https://github.com/golang/go/issues/13492

The Go project specifically acknowledging the glibc-isms here:

"All Linux first class ports are for systems using glibc only. Linux systems using other C libraries are not fully supported and are not treated as first class."

https://go.dev/wiki/PortingPolicy

Go only supporting static-init thread local storage, and thus their "C ABI" libraries can only be dlopen()'ed if the libc pre-allocates memory to hack in libraries later.

https://github.com/golang/go/issues/54805

[rsc]

If you just want to run Go programs on Alpine, it works fine. (I put some effort in back in Go 1.21 to make sure that the downloaded binary toolchains for Linux even work fine on Alpine.)

If you want to use c-shared mode and dlopen, then yes that only works with glibc, but that mode barely works at all anyway. It's not actively supported at all.

[jgowdy]

Respectfully, these vague states of support between “active” and less active, “first class” and not first class, etc comes off as “we want to say we have that but shrug any time it’s deficient.”

Its similar to calling the port overall “linux/<cpu-arch>” rather than “linux/<libc>/<cpu-arch>” which wouldn’t normally be called for except when you’re going to embed a bunch of a particular libc specific behavior in your consumption of libc.

Listening to Go advocates talk about C interop like it’s not only a solved problem but quite literally a strength of Go, while Go project leaders represent that support quite differently isn’t it. Perhaps clarification of these level of support terms and how the project embraces glibc specific behaviors unapologetically would help.