gccgo: GOARCH is not validated

[gm42]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.9 linux/amd64

Does this issue reproduce with the latest release?

Yes

What did you do?

$ GOARCH=386 go build -v -compiler gccgo ./mypkg/
go build: when using gccgo toolchain, please pass compiler flags using -gccgoflags, not -gcflags
mypkg
# mypkg
version.go:7:9: error: import file ‘strconv’ not found
  "strconv"
$ GOARCH=xxx go build -v -compiler gccgo ./mypkg/
go build: when using gccgo toolchain, please pass compiler flags using -gccgoflags, not -gcflags
mypkg
$ echo $?
0

What did you expect to see?

Failure when the provided GOARCH is invalid.

What did you see instead?

It builds for the default GOARCH.

If a valid architecture is provided it tries to build that one, failing if the standard library is not built for it. If a bogus one is provided, no errors are returned and the default one is picked instead.

[bradfitz]

/cc @ianlancetaylor

[ianlancetaylor]

In effect, GOARCH is ignored when using -compiler=gccgo. That is because the gccgo compiler, unlike the gc compiler, is not capable of building for multiple targets. You have to set the GCCGO environment to select the gccgo compiler you want to use.

I'm not sure what to do here.

[gm42]

@ianlancetaylor if it were ignored, then why I get an error when using GOARCH=386 (which I have not previously built)?

If you see the two commands I reported, I see some inconsistency there. First an error is reported (rightfully, I did not build 386 Go standard library there), then when GOARCH is set to xxx or any other gibberish, no errors happens because the amd64 standard library is being used.

[ianlancetaylor]

Hmmm, you're right, GOARCH=386 does cause the go tool to pass -m32 to gccgo. For a set of GOARCH values, the go tool will use explicit options. That set of values is not intended to be complete, though. The code is currently at https://golang.org/src/cmd/go/internal/work/build.go#L3243 .

[gm42]

Oh, interesting code you dug up. Thanks for the pointer; I see there also https://golang.org/src/cmd/go/internal/work/build.go#L3341 // TODO: make cgo not depend on $GOARCH?

I can give this a better look later, I seem to understand it is on purpose leaky as it can't be too tight on gccgo? I am okay to leave the issue open like this, or I could try submitting a PR but it would more be for proactive discussion on possible solutions/improvements rather than solving the problem, I understand it's hairy.