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

Jump to bottom

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

Closed
alexellis opened this issue Jan 24, 2017 · 12 comments
Closed

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

alexellis opened this issue Jan 24, 2017 · 12 comments
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Unplanned

Comments

@alexellis
Copy link

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
Copy link
Member

mvdan commented Jan 24, 2017

Dup of #18243?

@alexellis
Copy link
Author

@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
Copy link
Member

mvdan commented Jan 24, 2017

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

@minux
Copy link
Member

minux commented Jan 24, 2017 via email

@ALTree ALTree mentioned this issue Mar 2, 2017
Closed
@ALTree ALTree added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Mar 2, 2017
@ALTree ALTree added this to the Go1.9Maybe milestone Mar 2, 2017
@ALTree
Copy link
Member

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.

@bradfitz
Copy link
Contributor

@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
@broady
Copy link
Member

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
@bradfitz
Copy link
Contributor

Ping @ianlancetaylor and @rsc for a decision here.

@ianlancetaylor
Copy link
Contributor

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.

@rsc
Copy link
Contributor

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.

@rsc rsc modified the milestones: Go1.10, Go1.11 Dec 4, 2017
@bradfitz bradfitz modified the milestones: Go1.11, Unplanned May 18, 2018
@bradfitz bradfitz mentioned this issue Aug 27, 2018
Closed
@adamdecaf adamdecaf mentioned this issue Oct 7, 2018
Closed
@atc0005 atc0005 mentioned this issue Oct 8, 2020
Closed
@eliasnaur
Copy link
Contributor

Duplicate of #57007? If so, this can be closed.

@seankhliao
Copy link
Member

Duplicate of #57007

@seankhliao seankhliao marked this as a duplicate of #57007 May 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
10 participants
@bradfitz @broady @rsc @minux @eliasnaur @ianlancetaylor @mvdan @ALTree @alexellis @seankhliao