This is working as intended, ref #12808

@seankhliao This behavior is not at all implied by the current documentation for make.bash.

# CGO_ENABLED: Controls cgo usage during the build. Set it to 1
# to include all cgo related files, .c and .go file with "cgo"
# build directive, in the build. Set it to 0 to ignore them.

That does not make it clear that it is actually going to burn a default into the resulting compiler. Probably there need to be two different flags:

1. Should cgo be enabled while compiling?
2. What default value should be burned into the resulting compiler?

Please re-open this issue.

The current behavior is working as intended. We aren't going to change how CGO_ENABLED works today.

Reopening to clarify the documentation.

We aren't going to change how CGO_ENABLED works today.

@ianlancetaylor I'd like to request that you reconsider this. Today if I build a compiler targeting linux from an Alpine image (yes I know this isn't fully supported), then my options are either:

1. build with CGO_ENABLED=0, which has the unwanted side effect of producing a compiler that doesn't do cgo for the host by default
2. build without CGO_ENABLED=0 and produce an unusable compiler that is linked with musl

I think it would make more sense (and be more consistent) if there were CGO_ENABLED_FOR_$GOOS_$GOARCH environment variables, which set the defaults for the built compiler. This would accomplish two goals:

1. In my case, I would run with CGO_ENABLED=0 CGO_ENABLED_FOR_linux_amd64=1 and get the expected result.
2. People who are currently setting CC_FOR_$GOOS_$GOARCH can improve their experience by not having to explicitly set CGO_ENABLED=1 for a target for which they have pre-selected a C compiler.

I'm not opposed to adding CGO_ENABLED_FOR_${GOOS}_$(GOARCH} or perhaps more simply CGO_ENABLED_FOR_TARGET. What I'm opposed to is changing the current meaning of CGO_ENABLED.

We are planning some changes to the way cgo in std is handled, and it may be worth revisiting this behavior at that time. For now we should probably sit on this issue.

For anyone looking for a workaround for the original issue, on linux/amd64 you can explicitly set GOHOSTARCH=386 to fool make.bash into thinking it is doing a cross-compile, so it will produce a compiler without cgo that still has cgo enabled by default. Note that you will also need to install gcc-multilib, as the bootstrap compiler will still be compiled with cgo.