Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
make: always set CGO_ENABLED=0 for platform builds (#1200)
CGO_ENABLED defaults to "1" if a Go build targets the host system, so that it can use the system's libc and any other libraries. For cross-builds (when either the target GOOS or GOARCH don't match the host's), the Go tool can't assume that a C cross-compiler and the necessary headers are present, so the default is CGO_ENABLED=0. This can result in binaries published to NPM being inconsistently static, since the one matching the host's will be the only one to dynamically link C libraries. For example, on linux/amd64: $ make platform-linux platform-windows platform-linux-arm64 platform-darwin platform-freebsd [...] $ ldd npm/esbuild-*/bin/* npm/esbuild-darwin-64/bin/esbuild: not a dynamic executable npm/esbuild-freebsd-64/bin/esbuild: not a dynamic executable npm/esbuild-linux-64/bin/esbuild: linux-vdso.so.1 (0x00007ffd24570000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f35a6718000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f35a654b000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f35a6765000) npm/esbuild-linux-arm64/bin/esbuild: not a dynamic executable npm/esbuild-wasm/bin/esbuild: not a dynamic executable npm/esbuild-windows-32/bin/esbuild: not a dynamic executable npm/esbuild-windows-64/bin/esbuild: not a dynamic executable With this change, we always force CGO_ENABLED=0, and the resulting binaries are consistently non-dynamic no matter the host platform. This change should be safe, as esbuild seems to have zero cgo code, and the majority of platform builds for NPM were already defaulting to CGO_ENABLED=0.
- Loading branch information