build: release linux-amd64-nocgo statically linked binaries for Alpine users?

[alexellis]

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

Go 1.7.4

What operating system and processor architecture are you using (go env)?

$ uname -a
Linux alexellis 4.4.19-v7+ #906 SMP Tue Aug 23 15:53:06 BST 2016 armv7l GNU/Linux

What did you do?

If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.

The Go binary for ARM is built against libc instead of as a static binary, so when I try to run the Go binary on an Alpine Linux system I get an error (below)

I put together a Dockerfile which reproduces the issue on an ARMv6/7 board such as an RPi 2/3 - the below Dockerfile is +/- the same as the Official Docker golang image with the base image changed to an ARM compatible layer.

FROM armhf/alpine:latest
WORKDIR /root/

RUN mkdir -p /usr/local/go
RUN apk add --update libarchive-tools ca-certificates curl

ENV GOLANG_VERSION 1.7.4
ENV GOLANG_DOWNLOAD_URL https://golang.org/dl/go$GOLANG_VERSION.linux-armv6l.tar.gz
ENV GOLANG_DOWNLOAD_SHA256 075c5f4446234e26c1380003ff2b050f0c7e63591410bab65355a945601bf245

RUN curl -fsSL "$GOLANG_DOWNLOAD_URL" -o golang.tar.gz \
&& sha256sum golang.tar.gz \
    && echo "$GOLANG_DOWNLOAD_SHA256  golang.tar.gz" | sha256sum -c - \
    && bsdtar -C /usr/local -xzf golang.tar.gz \
    && rm golang.tar.gz

ENV GOPATH /go
ENV PATH $GOPATH/bin:/usr/local/go/bin:$PATH

RUN mkdir -p "$GOPATH/src" "$GOPATH/bin" && chmod -R 777 "$GOPATH"
WORKDIR $GOPATH

CMD ["go"]

What did you expect to see?

Go to function the same way as when I download the binary to a Debian-based system (which includes libc).

Having spoken to @justincormack from Docker we thought it would be good to have a statically-linked binary available so that using Golang on Alpine Linux does not need a complete re-build against musl.

What did you see instead?

/go # /usr/local/go/bin/go
go     godoc  gofmt
/go # /usr/local/go/bin/go
sh: /usr/local/go/bin/go: not found

[mvdan]

Dup of #18243?

[alexellis]

@mvdan I'm not strictly sure that's the case? It may be related though.

What I'm suggesting is that the Go binary distributed via (https://golang.org/dl/) itself is statically linked. Once Go is installed a number of flags are needed to produce distributable static binaries from source written in Go but that is a different issue.

[mvdan]

I'm not sure either; but both seem to be around the linker and the output is the same.

[minux]

Static linking multithreaded programs (I.e. all Go programs) against glibc has known problems: 1. The program still needs matching glibc version at runtime for nss. 2. There are known glibc issues with statically linking glibc programs. We shouldn't distribute known bad binaries. One workaround is perhaps add a bin/go.nocgo program that is built with the nocgo build tag.

[ALTree]

Pasting Ian's comment on #19365 (where they were asking the same thing):

To be honest, I think the right choice here is for people interested in Alpine to build their own binary distributions and make them available. We don't want to provide statically linked binaries by default, as the resulting go tool will not support go get in some configurations. We don't want to provide binaries for a wide range of different systems and configurations, because that is more work for us installing and maintaining the systems required to build them. And, frankly, we're going to make mistakes, and that is even more work. We provide binary downloads as a convenience for the largest sets of users. We can't provide binary downloads for all users.

[bradfitz]

@ianlancetaylor, we can automate the creation of static binaries in x/build/cmd/release as a new build configuration. In fact, we already have the -nocgo builder, so the majority of the work is already done. Adding a new binary type (hell, we have s390x) is just a few lines of config.

That doesn't mean we should do it necessarily, but I wouldn't include:

And, frankly, we're going to make mistakes, and that is even more work.

... in our decision making progress.

/cc @rsc @broady for thoughts.

[broady]

This sounds good from a process standpoint, but minux's comment and the quote from Ian above worry me.

What's the use case, here? From my experience building Docker images for Google Cloud, the binary releases include a lot of crud that most people building Docker images don't need. For example, the "tour" binary is included.

If you build from scratch, you get Go, and only Go. Maybe that's just better?

[bradfitz]

Ping @ianlancetaylor and @rsc for a decision here.

[ianlancetaylor]

I'm fine with adding a -nocgo (or a better name might be -static) option for binary builds, as long as it's not the default.