Compiled releases are dynamically linked

[keymon]

The releases published in this repo are dynamically linked:

$ file spruce
spruce: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

This can be a problem in scenarios like docker alpine. For instance, this Dockerfile, if you build it:

cat <<EOF > Dockerfile
FROM alpine:3.3

ENV SPRUCE_VERSION 0.13.0

RUN apk add --update wget ca-certificates \
  && wget https://github.com/geofffranks/spruce/releases/download/v${SPRUCE_VERSION}/spruce_${SPRUCE_VERSION}_linux_amd64.tar.gz \
  && tar -xvzf spruce_${SPRUCE_VERSION}_linux_amd64.tar.gz \
  && mv spruce_${SPRUCE_VERSION}_linux_amd64/spruce /usr/local/bin/ \
  && rm -rf spruce_${SPRUCE_VERSION}_linux_amd64* \
  && apk del wget ca-certificates \
  && rm -rf /var/cache/apk/*
EOF
docker build -t alpine-spruce .
docker run -i -t alpine-spruce ldd /usr/local/bin/spruce

It fails:

$ docker run -i -t alpine-spruce ldd /usr/local/bin/spruce
    /lib64/ld-linux-x86-64.so.2 (0x557b2cfc0000)
    libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x557b2cfc0000)
    libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x557b2cfc0000)
Error relocating /usr/local/bin/spruce: __vfprintf_chk: symbol not found

In this thread they discuss the topic and it seems that the magic solution is compile the binary with:

go build -tags netgo -installsuffix netgo .

Which indeed generates a static file:

$ file spruce 
spruce: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), statically linked, not stripped

[keymon]

It seems that go1.5 stabilises this:

$ go version
go version go1.5 linux/amd64
$ CGO_ENABLED=0 go build .
$ file spruce 
spruce: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), statically linked, not stripped

More info: https://golang.org/cmd/cgo/

[jhunt]

I believe this is a disparity between how gox and go build do things, and how goxc (used by release pipelines) does things:

$ gox -osarch linux/amd64
...
$ file spruce_linux_amd64
spruce_linux_amd64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped

@keymon: what happens if you just go build (without the -tags) on a Linux platform?

[keymon]

With both Go 1.4 and Go 1.5 it compiles dynamically:

$ cd $GOPATH/src/github.com/geofffranks/spruce
$ go build ./...
$ file spruce 
spruce: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped

But with GO 1.5, you can get a static binary if you set the environment variable CGO_ENABLED=0:

$ go version
go version go1.5 linux/amd64
$ CGO_ENABLED=0 go build ./...
$ file spruce 
spruce: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), statically linked, not stripped

Instead, with go 1.4, that environment variable does not work, and the workaround is using the -tags

$ go version
go version go1.4 linux/amd64
$ CGO_ENABLED=0 go build ./...
$ file spruce 
spruce: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
$ rm spruce 
$ go build -tags netgo -installsuffix netgo ./...
$ file spruce 
spruce: ELF 64-bit LSB  executable, x86-64, version 1 (SYSV), statically linked, not stripped

[keymon]

So, basically, if you compile it with Go 1.5 and export CGO_ENABLED=0, we should be fine.