This should work:

Copygo env -w CGO_ENABLED=1

---

But if you don't have a C compiler installed on your machine, you will get another error message after setting this variable and trying to use go run -race .:

cgo: C compiler "gcc" not found: exec: "gcc": executable file not found in %PATH%

If so, here are VS Code's instructions on how to install it

• Windows: https://code.visualstudio.com/docs/cpp/config-mingw
• Linux: https://code.visualstudio.com/docs/cpp/config-linux

Many things are only available as C libraries, and re-implementing that all in Go would be costly. cgo has its downsides, but it can be a good trade-off. Even the standard library uses it (net for DNS lookups, os/user for user lookups) because it doesn't re-implement 100% of the behaviour in Go.

Cross-compiling C code is still rather hard; you'll need the target architecture's C compiler and toolchain (e.g. CC=aarch64-linux-musl-gccgo build to build an arm64 binary). None of that is installed by default so for most people cgo simply won't work when cross-compiling; they need to take manual steps to set it up first.

cgo often isn't strictly required (like in the net and os/user packages), so disabling it by default seems the most user-friendly option.

But there are no such constraints on the native platform, and it's expected to work by default without any user setup; so why not enable it by default?

With CGO_ENABLED=0 you got a staticaly-linked binary (see: https://en.wikipedia.org/wiki/Static_build) so it will run without any external dependencies (you can buld your dockers from 'scratch' image) Like that: https://github.com/s0rg/microapp/blob/master/Dockerfile

In general, CGO_ENABLED=1 leads to faster, smaller builds & runtimes - as it can dynamically load the host OS's native libraries (e.g. glibc, DNS resolver etc.) - when running on the build OS. This is ideal for local rapid development. For deployment, CGO_ENABLED=1 may not be practical or even possible - when considering the deployment hosting OS.

If you're purely using the standard library, they you may not necessarily need CGO enabled. In certain standard libraries behavior will different if using a pure-Go version (CGO_ENABLED=0) or a CGO-enabled version:

• net: see DNS Name Resolution
• os/users:
  • CGO_ENABLED=1 uses the native OS (e.g. on Linux nsswitch) for ID lookup
  • CGO_ENABLED=0 uses a basic Go implementation (e.g. reads from /etc/passwd) - which does not include other ID registries the host may be aware of

Deployment

While a CGO_ENABLED=1 binary may be smaller in size, it relies on delivering a host OS too. Comparing Docker images:

• ubuntu:20.04 is 73.9MB (glibc: GNU-libc)
• alpine:3.12.1 is 5.57MB (musl libc)

so adding an OS (even a minimal one) adds this extra baggage. alpine looks attractive in its minimal size - but its libc may not be compatible with packages that rely on glibc.

CGO_ENABLED=0 is, however, ideal for scratch docker image deployments - as no host OS needs to be bundled.

However, if your application imports a package with C-code (e.g. go-sqlite3) then your build must enable CGO.

Hi @Nucl3arSn3k , If you use Bash, try CGO_ENABLED=1 go run main.go. (The syntax might differ for other shells.) The cgo command documentation says, The cgo tool is enabled by default for native builds on systems where it is expected to work. It is disabled by default when cross-compiling as wel…

Use zig cc https://zig.news/kristoff/building-sqlite-with-cgo-for-every-os-4cic