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

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

Closed
alexbrainman opened this issue Jul 14, 2016 · 9 comments
Closed
Milestone

Comments

@alexbrainman
Copy link
Member

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 pushed a commit to golang/exp that referenced this issue Jul 15, 2016
See issue golang/go#16368 for details.

Updates golang/go#16368

Change-Id: I6fe194b34ff9bb24d78e93a1bca76245385759f4
Reviewed-on: https://go-review.googlesource.com/24951
Reviewed-by: Nigel Tao <nigeltao@golang.org>
@gopherbot
Copy link

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

gopherbot pushed a commit to golang/sys that referenced this issue Jul 17, 2016
See issue golang/go#16368 for details.

Updates golang/go#16368

Change-Id: Ic3294385a350aee41887f59cbcf5b0af7742ff3b
Reviewed-on: https://go-review.googlesource.com/24952
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@quentinmit
Copy link
Contributor

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

@quentinmit quentinmit added this to the Go1.8 milestone Jul 20, 2016
@ianlancetaylor
Copy link
Contributor

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

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
Copy link
Member Author

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

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
Copy link
Member Author

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

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

@gopherbot
Copy link

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

gopherbot pushed a commit that referenced this issue Aug 28, 2016
genzabbrs.go uses whatever zoneinfo database available on the system.
This makes genzabbrs.go output change from system to system. Adjust
go:generate line to always use $GOROOT/lib/time/zoneinfo.zip, so it
does not matter who runs the command.

Also move go:generate line into zoneinfo.go, so it can be run
on Unix (see #16368 for details).

Fixes #15802.

Change-Id: I8ae4818aaf40795364e180d7bb4326ad7c07c370
Reviewed-on: https://go-review.googlesource.com/27832
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
albenik added a commit to albenik/go-serial-fork that referenced this issue Jan 29, 2017
To avoid cross platform go generate issue
Look at golang/go#16368
@golang golang locked and limited conversation to collaborators Aug 26, 2017
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

4 participants