With CGO_ENABLED=0 you got a staticaly-linked binary (see: https://en.wikipedia.org/wiki/Static_build) so it will run without any external dependencies (you can buld your dockers from 'scratch' image) Like that: https://github.com/s0rg/microapp/blob/master/Dockerfile

What it's saying you need to do is rebuild the library and runtime for linux-amd64. You can do that this way:

1. Find the root of your Go installation (if you don't know where this is, running which go may help - the binary is often installed with the rest of the sources).
2. cd into the src directory
3. Run GOOS=linux GOARCH=amd64 ./make.bash --no-clean (or GOOS=linux GOARCH=amd64 bash make.bash --no-clean if make.bash is not executable). This will rebuild the library and runtime using the specified OS and architecture.

Once you've done this, you can build a go package or binary for this architecture using GOOS=linux GOARCH=amd64 go build. You can follow the same instructions for other architectures and operating systems.

Edit (08/13/15):

As of Go 1.5, cross compiling is much easier. Since the runtime is written in Go, there's no need to set anything up in order to be able to cross-compile. You can now just run GOOS=<os> GOARCH=<arch> go build from a vanilla Go installation and it will work.

However, there's one exception to this. If you're using cgo, you'll still need to set stuff up ahead of time. And you'll need to inform the tooling that you want to enable cgo cross-compiling by setting the CGO_ENABLED environment variable to 1. So, to be precise:

1. cd into the src directory of your Go installation (see the instructions above).
2. Run CGO_ENABLED=1 GOOS=<os> GOARCH=<arch> ./make.bash --no-clean
3. Run CGO_ENABLED=1 go build to build your project. It is important that you specify CGO_ENABLED=1 even when you're compiling.

nope.

Many things are only available as C libraries, and re-implementing that all in Go would be costly. cgo has its downsides, but it can be a good trade-off. Even the standard library uses it (net for DNS lookups, os/user for user lookups) because it doesn't re-implement 100% of the behaviour in Go.

Cross-compiling C code is still rather hard; you'll need the target architecture's C compiler and toolchain (e.g. CC=aarch64-linux-musl-gccgo build to build an arm64 binary). None of that is installed by default so for most people cgo simply won't work when cross-compiling; they need to take manual steps to set it up first.

cgo often isn't strictly required (like in the net and os/user packages), so disabling it by default seems the most user-friendly option.

But there are no such constraints on the native platform, and it's expected to work by default without any user setup; so why not enable it by default?

@LinPy Thank you for u help.

https://www.x-cellent.com/blog/cgo-bindings/

I solved the problem. But build takes a long time, about 10 minutes, and I'm still looking for a better solution.

Images Dockerfile : https://github.com/sillyhatxu/alpine-build

CopyFROM xushikuan/alpine-build:2.0 AS builder

ENV WORK_DIR=$GOPATH/src/github.com/sillyhatxu/mini-mq

WORKDIR $WORK_DIR

COPY . .

RUN go build -a -ldflags "-linkmode external -extldflags '-static' -s -w" -o main main.go


FROM xushikuan/alpine-build:1.0

ENV BUILDER_WORK_DIR=/go/src/github.com/sillyhatxu/mini-mq
ENV WORK_DIR=/app
ENV TIME_ZONE=Asia/Singapore
WORKDIR $WORK_DIR
RUN ln -snf /usr/share/zoneinfo/$TIME_ZONE /etc/localtime && echo $TIME_ZONE > /etc/timezone
RUN mkdir -p logs
RUN mkdir -p db
RUN mkdir -p data

COPY --from=builder $BUILDER_WORK_DIR/main $WORK_DIR
COPY --from=builder $BUILDER_WORK_DIR/config.conf $WORK_DIR
COPY --from=builder $BUILDER_WORK_DIR/db $WORK_DIR/db
COPY --from=builder $BUILDER_WORK_DIR/basic.db $WORK_DIR/data
ENTRYPOINT ./main -c config.conf