5
votes

I am following the instructions on https://cloud.google.com/appengine/docs/go/googlecloudstorageclient/download to begin migrating some code from the, now deprecated, Files API to the new Cloud Storage API without success.

The steps I'm following are ...

I'm running appengine v1.9.23 which is later than the required appengine v1.8.1.

My $GOPATH is set, so I skip step #1.

I proceed to step #2:

goapp get -u golang.org/x/oauth2

goapp get -u google.golang.org/cloud/storage

I am not developing on a managed VM, so I skip step #3.

Now when I run the application, I get:

go-app-builder: Failed parsing input: parser: bad import "syscall" in goapp/src/golang.org/x/net/internal/nettest/error_posix.go

What am I doing wrong?


Steps to reproduce

% mkdir $HOME/myapp

I use a version that does not have the static resources:

application: myapp
version: alpha-001
runtime: go
api_version: go1

handlers:
- url: /.*
  script: _go_app
  • Create a location for the Go source files.

% mkdir $HOME/myapp/go

  • Set your GOPATH to the location of your sources

% export GOPATH=$HOME/myapp/go

% goapp get github.com/golang/example/appengine-hello

This command will download the example app to the first path entry in the GOPATH

% go get -u golang.org/x/oauth2

% go get -u google.golang.org/cloud/storage

  • Attempt to run your go application

% goapp serve

You will see the following compilation error (no stack trace):

2015/12/23 10:37:07 go-app-builder: Failed parsing input: parser: bad import "syscall" in go/src/golang.org/x/net/ipv6/control_unix.go

3
Possible duplicate of Golang Appengine Project won't build - icza
Within the context of the referenced question, my question could be stated: "Are Google's supplied instructions incorrect or am I doing something wrong? The instructions appear to direct the user to use an library that requires syscall support with a platform that doesn't support it." - Aaron Alpar
Is this error part of a larger stack trace? Could you provide more clear steps to how someone could reproduce this issue? - Nick
Nick - are you aware of a case where the instructions work for appengine-1.9.23? The setting of the GOPATH in Google's instructions are ambiguous and could effect the result of the compilation, although I have not found a value that produces a correct result. There is no stack trace for the error since it is a compilation error ("parse:"). - Aaron Alpar
I'm encountering the same thing and was about to ask this question myself. Have you found a resolution yet? - Curyous

3 Answers

2
votes

This error is caused by either of two scenarios:

1) Implicitly importing syscall by importing another package that uses it, as referenced in this related question.

2) Having your package source files in your GOPATH located in a directory at or below the same level as your project's app.yaml (eg. app.yaml in ~/go, and packages sources in ~/go/gopath/src). If a package like x/net/internal/nettest exists in your GOPATH the syscall import will be parsed by goapp at compile time and throw the compilation error.

Avoiding these two scenarios should be sufficient to prevent any bad import "syscall" errors or related compilation errors.

0
votes

Reproduced the initial steps above and got a similar error, even if not explicitly mentioning syscall. However, running “goapp serve” in the appengine-hello directory results in no error at all.

Adam’s explanation at point 2 applies here correctly: one needs to place the app.yaml file at the right level in the directory structure.

0
votes

sirupsen/logrus references syscall.

They have an appengine tag specified, not to include syscall so it's usable in AppEngine, something like go build -tags appengine as per issue 310.

However I haven't yet succeeded including it in an AppEngine project so that this build param could be forwarded and specified somewhere so that it goes through. I'll come back to update if I manage.