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

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

Open
aykevl opened this issue Mar 15, 2018 · 15 comments · May be fixed by #39176
Open

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

aykevl opened this issue Mar 15, 2018 · 15 comments · May be fixed by #39176
Milestone

Comments

@aykevl
Copy link

@aykevl aykevl commented Mar 15, 2018

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).

@gopherbot gopherbot added this to the Gccgo milestone Mar 15, 2018
@andybons andybons changed the title "unsupported GOOS/GOARCH pair" using gccgo - regression gccgo: "unsupported GOOS/GOARCH pair" using gccgo - regression Mar 15, 2018
@andybons
Copy link
Member

@andybons andybons commented Mar 15, 2018

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Mar 27, 2018

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

@aykevl
Copy link
Author

@aykevl aykevl commented Apr 10, 2018

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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 10, 2018

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
Copy link
Author

@aykevl aykevl commented Apr 10, 2018

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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 10, 2018

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
Copy link
Author

@aykevl aykevl commented Apr 10, 2018

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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Apr 11, 2018

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
Copy link
Author

@aykevl aykevl commented Apr 11, 2018

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
Copy link
Contributor

@aisk aisk commented May 12, 2020

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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 12, 2020

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

@aisk
Copy link
Contributor

@aisk aisk commented May 13, 2020

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
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented May 13, 2020

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
Copy link

@gopherbot gopherbot commented May 20, 2020

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

@gopherbot
Copy link

@gopherbot gopherbot commented Jun 4, 2020

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

gopherbot pushed a commit that referenced this issue Aug 14, 2020
The Builder isn't needed by MkEnv, and Builder.Init doesn't have side
effects that change the environment. Builder.Init does currently call
CheckGOOSARCHPair, but that's being moved out in CL 234658.

Builder.Init creates the temporary work directory used by the
builder. For the builder created in MkEnv, this directory is never
used. Creating this directory can cause unnecessary errors for
commands that don't use a builder like 'go clean' and 'go list'.

Fixes #38395
Updates #24398

Change-Id: Ib93ae55afdf958000470657f4c4ff5bd92700e46
Reviewed-on: https://go-review.googlesource.com/c/go/+/236563
Run-TryBot: Jay Conrod <jayconrod@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Michael Matloob <matloob@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants
You can’t perform that action at this time.