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

GOOS/GOARCH pair validity is checked before flags are parsed #43597

Closed
nevkontakte opened this issue Jan 8, 2021 · 6 comments
Closed

GOOS/GOARCH pair validity is checked before flags are parsed #43597

nevkontakte opened this issue Jan 8, 2021 · 6 comments

Comments

@nevkontakte
Copy link
Contributor

nevkontakte commented Jan 8, 2021

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

$ go version
go version go1.15.6 linux/amd64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/aleks/.cache/go-build"
GOENV="/home/aleks/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/aleks/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/aleks/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/aleks/sdk/go1.15.6"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/aleks/sdk/go1.15.6/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build684476333=/tmp/go-build -gno-record-gcc-switches"

What did you do?

$ GOARCH=foo GOOS=bar go1.15.6 build -compiler gccgo -v fmt

What did you expect to see?

Successful invocation of gccgo toolchain (possibly failing inside a gccgo).

What did you see instead?

cmd/go: unsupported GOOS/GOARCH pair bar/foo

Additional context

I am investigating integrating GopherJS compiler with standard go tooling as a third-party compiler similar to gccgo, in order to support GOOS=js GOARCH=js build target. This check is meant to be skipped for compilers other than gc, but CheckGOOSARCHPair() is called before compiler flag is parsed and set, causing a spurious error.

I suspect that there may be other checks that don't work as intended because they run against default flag values instead of real ones, I was able to find one example nearby, but probably there are more.

@nevkontakte
Copy link
Contributor Author

nevkontakte commented Jan 10, 2021

On a related note, it would be very helpful to be able to bypass GOOS/GOARCH validity check at the go tool level (perhaps with a special flag or environment variable). This would allow third-party Go implementations like GopherJS or TinyGo to use go list command or golang.org/x/tools/go/packages to gather information about builds that mainline Go toolchain doesn't support. Technically, the go tool can deal with any platforms, even if the compiler wouldn't be able to generate code for it. This, of course, shouldn't affect a similar check in the compile tool itself.

Let me know if this better be a separate feature request, and I'll file a new issue.

@bcmills
Copy link
Contributor

bcmills commented Jan 11, 2021

Duplicate of #24398

@bcmills bcmills marked this as a duplicate of #24398 Jan 11, 2021
@bcmills bcmills closed this as completed Jan 11, 2021
@nevkontakte
Copy link
Contributor Author

Thanks Bryan for triaging the issue and apologies for not finding the original one. Could you also comment on whether an option to disable this check would be a reasonable change? If so, I'll try to prepare a CL for it.

@bcmills
Copy link
Contributor

bcmills commented Jan 11, 2021

The check should already only occur when using the gc compiler, in which case it should correctly match the GOOS/GOARCH pairs supported by that compiler. See pending CL 234658.

@bcmills
Copy link
Contributor

bcmills commented Jan 11, 2021

Actually, I'm not sure that this is even still an issue. Have you tested with go1.16beta1?

@nevkontakte
Copy link
Contributor Author

Right, it does seem to work as expected with go1.16beta1, thanks. I also realized that the angle I'm looking at this from is a bit unusual and deserves its own discussion, so I a thread: https://groups.google.com/g/golang-nuts/c/xcQLrY4W7DI. Cheers!

@golang golang locked and limited conversation to collaborators Jan 11, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants