That won't fly: GOARCH=wasm GOOS=js
basically makes the Go compiler to produce wasm bytecode from the Go source. To spell this in other words, the Go code gets compiled to WASM bytecode and the WASM API calls instead of CPU-specific machine code and system calls to a particular OS kernel.
On the other hand, cgo
is a way to link the compiled C code with the compiled Go code. To compile a program making use of cgo
, the go
toolchain calls out to a real C compiler (gcc
most of the time), which compiles the C parts.
Compiled C code and WASM bytecode exist in different universes and do not know about each other. In theory, a C compiler such as gcc
could have a WASM backed—just like go
has now—but IIRC this is neither the case nor the Go's WASM backend is taught to somehow handle such a case.
All-in-all, the most typical case for using cgo
is interfacing with an already existing library written in C (or exposing a C-compatible API), and most of such libraries usually make profound assumptions about the environment they run in—which typically is a POSIX-compatible OS (with a set of syscalls to handle file and socket I/O and so on).
Hence if you are in a rare position of having the need to link with a "pure" C library—which performs pure data processing and does not communicate with an underlying OS in any way, it might be possible to look at a C-to-Go source-code translator.