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

Question

I could really use some help here. What I am trying to do is use the standard golang:1.5 Docker image to build a Go binary, then copy that binary out of the container and into a new minimal Docker container based on busybox. The binary is pulled out of the container using a Docker mounted volume. There are two problems so far that I have run into.

1. The resulting binary on the host (and subsequently copied into the second container) still seems to be a Mach-O 64-bit executable when running the file command. Is the Docker container somehow getting GOOS and GOARCH from the host?

2. When manually running the container with bash and building the Go binary, it now says it is an ELF executable but it is dynamically linked. I thought by default built statically linked binaries? I could just be wrong in this assumption.

Thanks in advance for any help you can provide.

EDIT: Here are the commands I am using. Hopefully this makes it a bit more clear

## 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'

Once the container is done running I have a Mach-O 64-bit executable in ./jenkins/out/. I'm not sure if this is some kind of weird behavior with docker-machine/boot2docker or anything like that. Just seems really weird. I have confirmed that if i set GOOS=linux GOARCH=amd64 before the go build command, then I do get an executable of the correct type. Just trying to figure out what is going on here.

Answer 1

It looks like you are still binding to some C libraries. This is a common problem when moving a Go executable to a super minimal container. You can roll these bound libraries into your executable by changing go build to CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o main . You can find some more information on this problem and how it relates to minimal docker builds at Codeship's blog.