Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

alexellis opened this issue Jan 24, 2017 · 10 comments


Copy link

@alexellis alexellis commented Jan 24, 2017

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 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_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 PATH $GOPATH/bin:/usr/local/go/bin:$PATH

RUN mkdir -p "$GOPATH/src" "$GOPATH/bin" && chmod -R 777 "$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
Copy link

@mvdan mvdan commented Jan 24, 2017

Dup of #18243?

Copy link

@alexellis alexellis commented Jan 24, 2017

@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 ( 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.

Copy link

@mvdan mvdan commented Jan 24, 2017

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

Copy link

@minux minux commented Jan 24, 2017

Copy link

@ALTree ALTree commented Mar 2, 2017

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.

Copy link

@bradfitz bradfitz commented May 24, 2017

@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.

@bradfitz bradfitz changed the title Official Go binary does not work in Alpine Linux (not statically linked) build: release linux-amd64-nocgo statically linked binaries for Alpine users? May 24, 2017
Copy link

@broady broady commented May 24, 2017

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 bradfitz modified the milestones: Go1.10, Go1.9Maybe Jun 29, 2017
Copy link

@bradfitz bradfitz commented Nov 28, 2017

Ping @ianlancetaylor and @rsc for a decision here.

Copy link

@ianlancetaylor ianlancetaylor commented Nov 28, 2017

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.

Copy link

@rsc rsc commented Dec 4, 2017

It's unclear how many Alpine users would use the download. Do we know? What's the full set of linux-*-nocgo that we'd want to post? Just amd64? arm? I don't really want to double our Linux distribution count.

It seems like we would want a strong indication of demand here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.