Golang for alpine does not honor "static" flags during build

[anusha-ragunathan]

golang:1.6.3-alpine
golang:1.7.1-alpine
golang:1.7.3-alpine

While using any of the above base images to build static go binaries using go install --ldflags '-extldflags "-static"' , only dynamic binaries are build.

As an alternative, using alpine as a base image and RUN apk add make go git gcc libc-dev works.

[tianon]

I'm currently using -v -ldflags '-d -s -w' to build static binaries, which does work for me on Alpine (specifically golang:1.7-alpine).

$ docker run -it --rm golang:1.7-alpine go tool link
...
  -d	disable dynamic executable
...
  -s	disable symbol table
...
  -w	disable DWARF generation

[justincormack]

Are you sure these are not static pie? These look like dynamic binaries but are not in fact linked to any libraries. The Alpine toolchain is now generating these by default I think, since 3.5.

Hmm, those are pre 3.5 though, so not sure that is the issue. I am using -buildmode pie --ldflags '-extldflags "-static"' to make sure I build static pie but that is with the alpine 3.5 base.

[anusha-ragunathan]

@tianon : I'm building simple go code here.

docker run -it golang:1.6-alpine sh

<create test.go with these contents>
/go # cat test.go
package main

import "fmt"
import _ "net"

func main() {
        fmt.Println("Hello world")
}

/go # go build test.go
/go # ldd test
        /lib/ld-musl-x86_64.so.1 (0x559dfc2b6000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x559dfc2b6000)

/go # go build -ldflags '-extldflags "-static"' test.go
/go # ldd test
        /lib/ld-musl-x86_64.so.1 (0x5647691ab000)
        libc.musl-x86_64.so.1 => /lib/ld-musl-x86_64.so.1 (0x5647691ab000)

Repeated test on golang:1.7-alpine and golang:1.8-alpine with the same results.

Using ldflags '-d -s -w' options throws cgo warnings.

[tianon]

Try adding -tags netgo -installsuffix netgo (which forces the all-Go networking implementation and should thus remove the cgo dependence).

[tianon]

(https://github.com/tianon/rawdns/blob/e110000a88714ab5872a8586c7edb33d630ea734/Dockerfile.cross#L6 is an example of somewhere I'm using this set of flags to successfully get fully-static binaries which work well on both Gentoo and Alpine in my own testing)

[anusha-ragunathan]

Passing the new set of flags does produce a static binary.
/go # go build -ldflags '-d -s -w' -a -tags netgo -installsuffix netgo test.go /go # ldd test ldd: test: Not a valid dynamic program
But this is more a workaround than a fix to the problem (why is "-static" not working really?). Not everyone will be aware of these flags. Also it takes longer to build simple go code with these flags.

/go # time go build -ldflags '-d -s -w' -a -tags netgo -installsuffix netgo test.go
real    0m 3.63s
user    0m 7.22s
sys     0m 0.30s

On an alpine image, the "static" flag works.

$ docker run -it alpine sh

/# apk update

/# apk add make go git gcc libc-dev

/# time go build -ldflags '-extldflags "-static"' test.go
real    0m 0.24s
user    0m 0.21s
sys     0m 0.04s

/ # ldd test
        ldd (0x55b62dbad000)

[tianon]

Well, with -static, you're not passing that to a Go tool at the end of the day -- you're passing that to an external linker, right? The solution I've posted (even though it's a bit verbose) is the official Go-upstream-sanctioned method for creating fully static binaries that import net.

The minimal version would be simply go build -ldflags '-d' -tags netgo -installsuffix netgo (using -d to tell Go's linker to create a static binary, -tags to tell the net package you want to not use libc, and -installsuffix to ensure that your -tags actually applies properly and consistently; see also golang/go#9369).

I personally add -a to ensure that all my code is recompiled at release-time and -s -w to shrink the binaries a bit by removing some debugging information (similar to using strip on C-based binaries).