Bad syscall import for cloud storage APIs

I follow the instructions at https://cloud.google.com/appengine/docs/go/googlecloudstorageclient/download to easily transfer some code from the API now without outdated API files to the new cloud storage API.

I follow these steps:

I am running appengine v1.9.23, which is later than the required appengine v1.8.1.

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

Go to step # 2:

goapp get -u golang.org/x/oauth2

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

I am not developing a managed virtual machine, so I will skip step number 3.

Now, when I launch 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?


Playback Steps

% mkdir $HOME/myapp

I am using a version that does not have 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 GOPATH to the location of your sources.

% export GOPATH=$HOME/myapp/go

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

This command will load the sample application into the first path entry in GOPATH

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

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

  • Trying to run your application

% goapp serve

You will see the following compilation error (without 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

+5
source share
3 answers

This error is caused by one of two scenarios:

1) Implicitly import syscall by importing another package that uses it, as indicated 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 app.yaml project (for example, app.yaml in ~ / go and packages in ~ / go / gopath / SRC) . If a package such as x/net/internal/nettest nettest exists in your GOPATH, then syscall import will be analyzed during compilation and it will throw a compilation error.

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

+4
source

Playing the initial steps above also got a similar error, even if syscall is not explicitly mentioned. However, running "goapp serve" in the appengine-hello directory does not produce an error.

Adams explains in paragraph 2 here correctly: you need to put the app.yaml file at the desired level in the directory structure.

0
source

sirupsen/logrus refers to syscall .

They include an appengine tag that does not include a system call so that it can be used in AppEngine, something like go build -tags appengine according to release 310 .

However, I have not yet been able to include it in the AppEngine project so that this assembly parameter can be sent and pointed somewhere so that it passes. I will come back to update if I succeed.

0
source

Source: https://habr.com/ru/post/1237609/


All Articles