Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make: always set CGO_ENABLED=0 for platform builds #1200

Merged
merged 1 commit into from
Apr 26, 2021

Conversation

mvdan
Copy link
Contributor

@mvdan mvdan commented Apr 26, 2021

(see commit message)

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.
@evanw
Copy link
Owner

evanw commented Apr 26, 2021

Thanks for the detailed description. I wasn't aware of this issue. Sounds good to me.

@evanw evanw merged commit 20ef31e into evanw:master Apr 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants