gccgo: "unsupported GOOS/GOARCH pair" using gccgo - regression

[aykevl]

It looks like issue #12272 is back in go 1.10, while it was still gone in go 1.9.4. It emits this error "unsupported GOOS/GOARCH pair" even when using -compiler=gccgo. As per #12272 (comment), I think it should be fixed again.

Go version: go1.10 linux/amd64

Note: I'm trying to write a cross-compiler wrapper to the ESP32 (see here), which compiles with GOOS=esp32 and GOARCH=xtensa (I had to choose something for those values).

[andybons]

@ianlancetaylor

[ianlancetaylor]

I can't recreate this. Please show us the exact command that you are running and the exact output that you see. Thanks.

[aykevl]

Here is a way to reproduce:

$ GOOS=linux GOARCH=xtensa go build -compiler=gccgo gohello
cmd/go: unsupported GOOS/GOARCH pair linux/xtensa

Note that it also fails when not doing any building, as with the following command:

$ GOOS=linux GOARCH=xtensa go version
cmd/go: unsupported GOOS/GOARCH pair linux/xtensa

Background: I was trying to build a wrapper around the go command to build very simple Go programs for the ESP32. This worked, somewhat: I got a blinking light and working goroutines/channels, but I dropped the project. I had to switch to go <1.10 for building it.

[ianlancetaylor]

OK, I can recreate this if I use the gc version of the go tool, but not if I use the gccgo version of the go tool. Is that what you are doing?

[aykevl]

I'm not entirely sure what you mean? Are there two different versions of the go command?
I downloaded the go toolchain from https://golang.org/dl and executed the command as in the previous comment.

[ianlancetaylor]

Yes, there are two slightly different versions of the go command. If you install gccgo, you will get a gccgo-specific version of the command, which will default to -compiler=gccgo. If you do not install gccgo, you won't be able to use gccgo anyhow. Simply downloading the gc toolchain from golang.org/dl will not make -compiler=gccgo work; you must also install gccgo.

[aykevl]

Actually, I have gccgo installed, from the Debian archive (Debian stretch). So that shouldn't be the problem.

Note that I have used go build -compiler=gccgo, with a version downloaded from golang.org, it's just that the latest version stopped working. As far as I can see, everything is equal in my configuration except for the go tool version.

~$ which go
/usr/local/go/bin/go

~$ /usr/local/go/bin/go version
go version go1.10 linux/amd64

~$ /usr/local/go1.8/bin/go version
go version go1.8.3 linux/amd64

~$ GOOS=linux GOARCH=xtensa /usr/local/go/bin/go build -compiler=gccgo foobar
cmd/go: unsupported GOOS/GOARCH pair linux/xtensa

~$ GOOS=linux GOARCH=xtensa /usr/local/go1.8/bin/go build -compiler=gccgo foobar
can't load package: package foobar: cannot find package "foobar" in any of:
	/usr/local/go/src/foobar (from $GOROOT)
	/home/ayke/src/foobar (from $GOPATH)

[ianlancetaylor]

If you have installed gccgo, then in the same directory as the gccgo executable there is a go executable. Run that instead of /usr/local/go/bin/go.

I'm not saying that there isn't a bug here. There is a bug. I'm just giving you a workaround.

[aykevl]

Ah, I didn't know about that! Thanks for the hint.
On my Debian installation it seems to be called x86_64-linux-gnu-go-6.

$ GOOS=linux GOARCH=xtensa x86_64-linux-gnu-go-6 version
go version go1.6.1 gccgo (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 linux/amd64

[aisk]

I think the go command error message is a little bit misleading. In the issue's case, -compiler=gccgo specified gccgo as compiler, but it's not in PATH, but the actully error message is cmd/go: unsupported GOOS/GOARCH pair darwin/xtensa.

I think it's better to show something like this:

cmd/go: gccgo: exec: "gccgo": executable file not found in $PATH

[ianlancetaylor]

Yes, we agree there is a bug here. Want to send a patch? Thanks.

[aisk]

I took a dig and found that the root cause is that before real buildCmd we ran the MkEnv() here to have a guarantee for we set up all the config.

But this leading to call cmd/go/internal/work.Builder.Init, and this function will validate the OS/ARCH pair and may cause exit. And at that moment, the buildCmd is not executed and the -compiler flag is not parsed, so we can't check it at that time.

I thought we can add a noexit flag in the cmd/go/internal/work.Builder.Init to let ignore the validation, or just return an error and let the caller to decide should call exit.

@ianlancetaylor what do you think, or have other idea?

[ianlancetaylor]

Seems to me that we should just move the call to CheckGOOSARCHPair to later. For example, perhaps we could call it from BuildInit. But I haven't really looked at this.

[gopherbot]

Change https://golang.org/cl/234658 mentions this issue: cmd/go: delay os/arch pair check for better error message

[gopherbot]

Change https://golang.org/cl/236563 mentions this issue: cmd/go: don't initialize Builder in envcmd.MkEnv

[bcmills]

Is there anything more needed for this issue?

I'm seeing the following with a go command build from head:

$ go version
go version devel +59bfc18e3 Fri Jan 8 22:55:41 2021 +0000 linux/amd64

$ go mod init example.com
go: creating new go.mod: module example.com

$ /usr/bin/which gccgo

$ cat > main.go
package main

func main() {}

$ GOARCH=xtensa GOOS=linux go build -compiler=gccgo .
cmd/go: gccgo: exec: "gccgo": executable file not found in $PATH

That seems to match the desired behavior described in #24398 (comment).