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

Closed
aykevl opened this issue Mar 15, 2018 · 17 comments
Closed

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

aykevl opened this issue Mar 15, 2018 · 17 comments
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@aykevl
Copy link

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 andybons added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Mar 15, 2018
@andybons
Copy link
Member

@ianlancetaylor

@ianlancetaylor
Copy link
Contributor

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

@andybons andybons added WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. and removed NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. labels Mar 30, 2018
@aykevl
Copy link
Author

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 ianlancetaylor added NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. and removed WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. labels Apr 10, 2018
@ianlancetaylor
Copy link
Contributor

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

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

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

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

@ianlancetaylor ianlancetaylor added help wanted NeedsFix The path to resolution is known, but the work has not been done. labels May 12, 2020
@ianlancetaylor ianlancetaylor modified the milestones: Gccgo, Backlog May 12, 2020
@gopherbot gopherbot removed the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 12, 2020
@aisk
Copy link
Contributor

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

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

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

@gopherbot
Copy link

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

bcmills commented Jan 11, 2021

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

@seankhliao seankhliao modified the milestones: Backlog, Gccgo Aug 20, 2022
@aykevl
Copy link
Author

aykevl commented Aug 21, 2022

FYI: I'm not using GOARCH=xtensa go build ... etc anymore, there are too many things that don't work with that configuration. So feel free to close this.

@golang golang locked and limited conversation to collaborators Aug 21, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants