syscall: cannot use go generate to invoke mksyscall_windows.go on linux

[alexbrainman]

Before go1.7 I could use go generate to generate $GOROOT\src\syscall\zsyscall_windows.go on my Linux computer. Not anymore:

# cd $GOROOT/src/syscall                                                 
# go version                                                             
go version devel +a1110c3 Tue Jul 12 19:18:08 2016 +0000 linux/386                   
# GOOS=windows go generate                                               
fork/exec /tmp/go-build001548608/command-line-arguments/_obj/exe/mksyscall_windows.exe: exec format error                                                                 
syscall_windows.go:17: running "go": exit status 1                                   
#                                                                        

This is because go generate command respect GOOS and GOARCH now. I tried running go generate without GOOS=windows, but it does nothing because //go:generate is in syscall_windows.go (windows only file).

Ian suggested (#16120 (comment)) we should move //go:generate line into syscall.go.

We have other packags std and x/... that use mksyscall_windows.go in a similar fashion. This issue is to make sure everything is fixed.

Alex

[gopherbot]

CL https://golang.org/cl/24952 mentions this issue.

[quentinmit]

Does this commit actually fix anything? Won't GOOS and GOARCH still be set to the wrong values when running the go:generate commands?

[ianlancetaylor]

In the case of the syscall package, the mksyscall_windows command does not care about GOOS or GOARCH. The problem Alex was encountering is that he is setting GOOS=windows so that the go tool sees the go:generate command in syscall_windows.go, but now that GOOS=windows setting is passed on to go run, and so the go tool builds a Windows executable, which then fails to run. The fix is to move the go:generate command to a different file, so that it is not necessary to set GOOS=windows for go generate.

[quentinmit]

Aha, this change makes it work if you run go generate without GOOS set. I was thinking of the case where someone has GOOS set in their environment already, and it will be passed through no matter which file the go:generate is in.

[alexbrainman]

Aha, this change makes it work if you run go generate without GOOS set.

Yes, that is how I am going to use this tool in the future.

I was thinking of the case where someone has GOOS set in their environment already, and it will be passed through no matter which file the go:generate is in.

I don't understand the scenario you are describing. Please provide a particular example.

We use "go run ..." command here. So if you set GOOS != GOHOSTOS, then it will not work - you will get confusing error message just like mine above.

Alex

[quentinmit]

I was thinking of the case where someone has GOOS set in their environment already, and it will be passed through no matter which file the go:generate is in.
I don't understand the scenario you are describing. Please provide a particular example.

We use "go run ..." command here. So if you set GOOS != GOHOSTOS, then it will not work - you will get confusing error message just like mine above.

I was thinking of:

export GOOS=windows
go generate std
go build std

or something along those lines. I was thinking that a fix would be to make the go:generate comment be something like

env GOOS=$GOHOSTOS  GOARCH=$GOHOSTARCH go run ...

[alexbrainman]

I was thinking of

I tried that, and I get same error as before. I don't see anything different from my approach that I've described in the bug itself.

env GOOS=$GOHOSTOS GOARCH=$GOHOSTARCH go run ...

I don't think this will fly on windows, if you expect Windows cmd.exe to interpret your command line as is. There is no "env" command. You cannot set global variables on the same command line. And cmd.exe does not use $ for environment variables.

And I don't think we want to change "go generate" to "process" its command lines before passing them to the OS.

Anyway Ian's suggestion works for me for the moment. I had to add odd source file here or there, but it is small price to pay.

Alex

[gopherbot]

CL https://golang.org/cl/27411 mentions this issue.

[gopherbot]

CL https://golang.org/cl/27832 mentions this issue.