There are several other environment variables documented here:

https://golang.org/cmd/go/#hdr-Environment_variables

We should include all of them, not just GOARM and GO386

/cc @rsc

Should we show the CGO-related environment variables when CGO_ENABLED=0?

Also, we're currently showing an environment variable called GOGCCFLAGS, but that's not actually documented as an environment variable. Should I remove that? (Presumably not, for backwards compatibility.)

go env GOGCCFLAGS is useful, so we shouldn't remove it. But it's true that it's kind of problematic. Setting the environment variable GOGCCFLAGS does nothing other than change the output of go env. But go env GOGCCFLAGS is useful to pick up the options to pass to the C compiler, which go env currently does not display in any other way.

@ianlancetaylor AFAICT the go command does not actually read the GOGCCFLAGS environment variable. It is completely ignored if set in the environment. The actual environment variable to set is CGO_CFLAGS or CGO_CPPFLAGS, though I think those are not actually reflected in the value of GOGCCFLAGS either.

Yes, you're right. (But go env GOGCCFLAGS is still useful.)

A few more questions that came up:

• GCCGO contains the name of the gccgo executable to use. But whether or not gccgo is installed, it defaults to the value gccgo. I could instead print the path of the actually-found gccgo executable, but then you'd see GCCGO="" if there is no GCCGO. Is that okay?
• There is an undocumented CGO_FFLAGS environment variable. Document and print in go env? Or omit?
• Should GOARM and GO386 always be shown, or only if GOARCH is set to a value that they have an effect on?

I think that if we add support for go env GCCGO then it should print gccgo if there is no gccgo on PATH.

We should treat CGO_FFLAGS like CGO_CFLAGS.

My opinion is that we should always print the same set of environment variables from go env, though unfortunately that is already broken as we skip some variables on plan9.

CL https://golang.org/cl/31330 mentions this issue.

@ianlancetaylor
So unfortunately the default value of CGO_CFLAGS cannot be printed; it normally defaults to -g -O2 but when we run go tool cgo it defaults to an empty string. If the environment variable is actually set, it is used for both go tool cgo as well as all other compiles.

So I'm left with the only option being to show the actual value of the CGO_CFLAGS environment variable, defaulting to the empty string. I don't love that because it doesn't reveal that -g -O2 is being used by default.

I think I also have to therefore not show the defaults for the other CGO_* environment variables, or else it will again cause confusion because users will think CGO_CFLAGS defaults to empty when the others do not.

Thoughts?

As far as I know, go tool cgo does not use CGO_CFLAGS at all. It simply invokes the cgo tool, and the cgo tool takes the compiler options on the command line, not in the environment (except for CGO_LDFLAGS, sigh).

Given that it seems to me that if CGO_CFLAGS is not set then showing the value as "-g -O2" is reasonable.

By the way, if any of this seems too crazy we can probably change it.

go build uses CGO_CFLAGS when it invokes go tool cgo.

See https://github.com/golang/go/blob/master/src/cmd/go/build.go#L3208

If CGO_CFLAGS is unset, cgoCFLAGS gets the value -g -O2 and cgoexeCFLAGS gets an empty value. If CGO_CFLAGS is set, both cgoCFLAGS and cgoexeCFLAGS get the value of the environment variable. cgoexeCFLAGS is passed to go tool cgo on L3287.

When I say go build and go tool cgo I am referring to two different command line options. You are of course correct that when go build invokes the cgo tool it passes CGO_CFLAGS. Perhaps my comment will make more sense with that understanding.