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: GOARCH is not validated #23566

Open
gm42 opened this issue Jan 26, 2018 · 5 comments

Comments

@gm42
Copy link

commented Jan 26, 2018

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.

@ALTree ALTree changed the title GOARCH is not validated gccgo: GOARCH is not validated Jan 26, 2018

@gopherbot gopherbot added this to the Gccgo milestone Jan 26, 2018

@bradfitz

This comment has been minimized.

Copy link
Member

commented Jan 26, 2018

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jan 26, 2018

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

This comment has been minimized.

Copy link
Author

commented Jan 27, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 27, 2018

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

This comment has been minimized.

Copy link
Author

commented Jan 29, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.