A regression between 1.6 and 1.7, and should be easy to fix. Slating for 1.7.

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

Before this change 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                                   
#                                                                        

What do you propose I do now? Thank you.

A regression between 1.6 and 1.7

This is not a regression from go1.6. I have no problem building $GOROOT\src\syscall\zsyscall_windows.go with go1.6.2.

I am not sure that new behavior is better? What was the original problem?

Alex

@alexbrainman I think the fix for the program running go generate in the syscall package is to move the //go:generate comment from syscall_windows.go to syscall.go. The go generate command runs fine on any system; the only reason you are using GOOS=windows is so that go generate will look in syscall_windows.go.

I agree with the change in this issue--I think go generate should pass GOOS and GOARCH to the child process. Otherwise there is no simple way to get that information.

I think the fix for the program running go generate in the syscall package is to move the //go:generate comment from syscall_windows.go to syscall.go

OK. Thank you.
#16368

Alex