hub: Problem with the linux binaries on Alpine

Note, there is a package for Alpine, but in ‘testing’ repository, which you should enable explicitly: https://pkgs.alpinelinux.org/packages?name=hub

install until then with

apk add --no-cache -X http://dl-cdn.alpinelinux.org/alpine/edge/testing hub

Something like this would statically compile:

CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-extldflags "-static"' .

This is passing -static to the external linker and disabling cgo (i.e. disable the ability to call c code. Not sure if it’s required or not but all the examples I’ve seen disable it).

@mislav it’s a glibc vs musl issue

Most go binary projects I’ve seen (gosu for example) compile binary in such a way that they are statically linked. For some reason, the hub executable is not statically linked, and thus needs glibc. ldd shows this.

docker run -it --rm alpine:3.8

apk add --no-cache wget
wget https://github.com/tianon/gosu/releases/download/1.10/gosu-amd64
chmod 755 gosu-amd64
ldd gosu-amd64
./gosu-amd64

Shows

/ # ldd gosu-amd64
ldd: gosu-amd64: Not a valid dynamic program

But that one gosu exectuable works on both glibc and musl linux alike.

For some reason, the hub downloaded from the release page shows this

/hub/bin # ldd hub
        /lib64/ld-linux-x86-64.so.2 (0x7fe2c974c000)
        libpthread.so.0 => /lib64/ld-linux-x86-64.so.2 (0x7fe2c974c000)
        libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7fe2c974c000)

Unfortunately, I don’t know about golang to explain how you fix it. But if you start statically linking the hub executable, then the release downloads will work for both.

Note, there is a package for Alpine, but in ‘testing’ repository, which you should enable explicitly: https://pkgs.alpinelinux.org/packages?name=hub

Adding environment variable CGO_ENABLED=0 before go build should solve this issue.

Thank you @philwinder @andyneff. I’ve also been reading https://medium.com/@diogok/on-golang-static-binaries-cross-compiling-and-plugins-1aed33499671 which suggests:

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -a \
  -tags netgo -ldflags '-w -extldflags "-static"' -o mybin *.go

Now the question is, which precompiled builds should I apply these flags to? Or, should I make a separate precompiled build with these settings? When to instruct people in the install docs to try downloading that build?

Some projects go as far as to release a dynamic-glibc, dynamic-musl, and static-go variant. You can also statically compile using C libs instead of netgo /w -linkmode external using either musl (MIT) or glibc (GPL), subject to the respective license.

Thanks for the tips.

Since existing linux build seem to work (at least, there were no complains until now) for most people except those who use Alpine, I don’t want to risk kicking the hornet’s nest by changing the build configuration for those. Instead, I agree that we could offer alternate builds. But since I’m short on time and this issue personally doesn’t affect me, I would like yours or others’ help on figuring out what the exact build flags should be, and how to call this build. If we’re doing this primarily to benefit Alpine users, should we name the build “alpine”? Or, if this is just for alpine, maybe we can go the dynamic-musl route?

Reopening

Hi I can’t help you with linux commands and making docker containers. You’ll have to figure it out on your own.

For what it’s worth, this script installs hub into /usr/local/bin/hub:

mkdir hub && \
wget https://github.com/github/hub/releases/download/v2.5.0/hub-linux-amd64-2.5.0.tgz -O- | \
tar xz --strip-components 1 --directory hub && \
./hub/install && rm -r hub

You can change the installation location with PREFIX=/usr when running the install script. The $PREFIX/bin directory should be in your PATH before you can run hub.