Docker 容器内构建的 Golang 二进制文件，仍然是 Mach-O 可执行格式？

Question

我真的可以在这里使用一些帮助。我想要做的是使用标准的 golang:1.5 Docker 镜像来构建一个 Go 二进制文件，然后将该二进制文件从容器中复制到一个基于 busybox 的新的最小 Docker 容器中。使用 Docker 安装的卷将二进制文件从容器中拉出。到目前为止，我遇到了两个问题。运行file命令时，主机上生成的二进制文件（随后复制到第二个容器中）似乎仍然是 Mach-O 64 位可执行文件。Docker 容器是否以某种方式从主机获取 GOOS 和 GOARCH？当手动运行容器bash并构建 Go 二进制文件时，它现在说它是一个 ELF 可执行文件，但它是动态链接的。我认为默认情况下构建静态链接的二进制文件？我在这个假设中可能是错误的。预先感谢您提供的任何帮助。编辑：这是我正在使用的命令。希望这让它更清楚一点## golang:1.5 base image with WORKDIR set to $GOPATH/src/myproject the source## for the project was added in when creating the 'mybuild_img' docker image## GOPATH is set automatically in the golang image.docker run -i -v `pwd`/jenkins/out:$GOPATH/src/myproject/jenkins/out mybuild_img:latest bash -c 'go build && cp myproject ./jenkins/out'容器运行完毕后，我在 ./jenkins/out/ 中有一个 Mach-O 64 位可执行文件。我不确定这是否是 docker-machine/boot2docker 或类似的某种奇怪行为。只是看起来真的很奇怪。我已经确认，如果我GOOS=linux GOARCH=amd64在go build命令之前设置，那么我确实得到了正确类型的可执行文件。只是想弄清楚这里发生了什么。

Answer 1

看起来您仍然绑定到某些 C 库。这是将 Go 可执行文件移动到超小型容器时的常见问题。你可以通过改变这些滚动绑定库到可执行 go build 到 CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main .你可以找到关于这个问题的一些详细信息，以及它如何涉及最搬运工建立在Codeship的博客。