【问题标题】:bad import "syscall" for cloud storage APIs云存储 API 的错误导入“系统调用”
【发布时间】:2015-12-07 22:37:15
【问题描述】:

我正在按照 https://cloud.google.com/appengine/docs/go/googlecloudstorageclient/download 上的说明开始将一些代码从现已弃用的 Files API 迁移到新的 Cloud Storage API,但没有成功。

我正在遵循的步骤是......

我正在运行的 appengine v1.9.23 比所需的 appengine v1.8.1 晚。

我的 $GOPATH 已设置,所以我跳过第 1 步。

我继续第 2 步:

goapp get -u golang.org/x/oauth2

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

我不在托管 VM 上进行开发,因此我跳过了第 3 步。

现在当我运行应用程序时,我得到:

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

我做错了什么?


重现步骤

% mkdir $HOME/myapp

我使用的版本没有静态资源:

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

handlers:
- url: /.*
  script: _go_app
  • 为 Go 源文件创建一个位置。

% mkdir $HOME/myapp/go

  • 将您的 GOPATH 设置为源的位置

% export GOPATH=$HOME/myapp/go

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

此命令会将示例应用程序下载到 GOPATH 中的第一个路径条目

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

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

  • 尝试运行您的 Go 应用程序

% goapp serve

您将看到以下编译错误(无堆栈跟踪):

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

【问题讨论】:

  • 在所引用问题的上下文中,我的问题可以表述为:“Google 提供的说明是错误的还是我做错了什么?这些说明似乎指示用户使用需要 @987654342 的库@支持一个不支持它的平台。”
  • 这个错误是更大的堆栈跟踪的一部分吗?您能否提供更明确的步骤来说明如何重现此问题?
  • Nick - 您是否知道说明适用于 appengine-1.9.23 的情况? Google 说明中的 GOPATH 设置不明确,可能会影响编译结果,尽管我还没有找到产生正确结果的值。该错误没有堆栈跟踪,因为它是一个编译错误(“parse:”)。
  • 我遇到了同样的事情,正要自己问这个问题。你找到解决办法了吗?

标签: google-app-engine go


【解决方案1】:

此错误是由以下两种情况之一引起的:

1) 通过导入另一个使用syscall 的包来隐式导入syscall,如this related question 中所引用。

2) 将您的包源文件放在您的GOPATH 中,该目录位于与您项目的 app.yaml 相同或低于同一级别的目录中(例如 ~/ 中的 app.yaml go,并将源码打包在~/go/gopath/src)。如果您的 GOPATH 中存在类似 x/net/internal/nettest 的包,则 syscall 导入将在编译时由 goapp 解析并抛出编译错误。

避免这两种情况应该足以防止任何bad import "syscall" 错误或相关的编译错误。

【讨论】:

  • 解释清楚,谢谢!对于 1) 一个典型的罪魁祸首是“net”包(因此任何自定义 TCP/UDP/Unix 套接字代码),因为它导入系统调用。 2) 我认为stackoverflow.com/a/48132666/3072751 提供了一个很好的解决方案,如果您使用的是 vendor/。
【解决方案2】:

重现了上面的初始步骤并得到了类似的错误,即使没有明确提到系统调用。但是,在 appengine-hello 目录中运行“goapp serve”完全不会出错。

Adam 在第 2 点的解释在这里正确适用:需要将 app.yaml 文件放在目录结构中的正确级别。

【讨论】:

    【解决方案3】:

    sirupsen/logrus 引用 syscall

    他们指定了一个 appengine 标签,不包括系统调用,因此它可以在 AppEngine 中使用,就像 go build -tags appengine 一样,根据 issue 310

    但是我还没有成功地将它包含在 AppEngine 项目中,以便可以将这个构建参数转发并指定到某个地方以便它通过。如果我成功了,我会回来更新。

    【讨论】:

      猜你喜欢
      • 2015-10-30
      • 2017-08-20
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-02-18
      • 2022-08-20
      • 1970-01-01
      相关资源
      最近更新 更多