Consider distributing statically built binaries as part of release

[ahmetb]

Currently if you're not using Fedora, you're kinda outta luck and you have to build from source. When I see a project written in Go, it's sad to see it just cannot be built directly with go tool, or doesn't offer binary builds.

Travis CI can attach binaries to your releases. For example: https://github.com/ahmetb/govvv/releases

You can use https://github.com/mitchellh/gox to provide cross platform builds in your travis build or so.

Please consider distributing binary builds.

[mtrmac]

If that is useful least for macOS (static linking device-mapper on Linux might not be a good idea), that would be nice. It would be much more likely likely to happen if someone contributed the automation to do this, though.

[git001]

I would be also very helpful got have some windows binaries as a lot of developer are still on windows.

[rhatdan]

Might have an intern look at this.

[jkroepke]

@rhatdan 10 months ago. Do you have news?

The static binary also works on any systems that go supports. Providing static builds for linux can resolve (#594), since the library link variant looks impossible to solve.

[mhagnumdw]

Any news here?

[mtrmac]

For Linux, there are now official containers, courtesy of @TomSweeneyRedHat ; see #432 (comment) . Still, the default recommendation is to use the build packaged in your distribution.

On macOS, similarly, there is a formula maintained by the Homebrew project.

I am not aware of any work on Windows.

[mtrmac]

For the record, there’s also #330 with a fair bit of overlap.

[seandilda]

Having official containers is great. Can we get official binaries as well so we can easily add them to our own containers (without having to pull them out of the other containers)?

I can install kubectl, helm, and oc all by using curl to pull in an official binary. Why is skopeo different?

[mtrmac]

Why is skopeo different?

#594 (comment)

[jkroepke]

@mtrmac

Correct me if I'm wrong but #594 (comment) looks not related to this since the pure go static version (make binary-static DISABLE_CGO=1) does not include libdevmapper?

[mtrmac]

Well, that one is not handling NSS consistently with the rest of the system. None of them work well enough to be worth recommending over a distribution package.

[jkroepke]

@mtrmac

Well, that one is not handling NSS consistently with the rest of the system.

Could you explain this limitation a little bit more please? Resolution via /etc/hosts work well if compiled via make binary-static DISABLE_CGO=1.

A quick test:

bash-4.4# grep hosts.test /etc/hosts
127.0.0.4  hosts.test
bash-4.4# env GODEBUG=netdns=cgo+1 skopeo inspect docker://hosts.test/jkr/centos:7
go package net: using cgo DNS resolver
FATA[0000] Error parsing image name "docker://hosts.test/jkr/centos:7": error pinging docker registry hosts.test: Get https://hosts.test/v2/: dial tcp 127.0.0.4:443: connect: connection refused

For me, it looks like even if DISABLE_CGO=1 is set on compile time, a cgo dns resolver is available which using getaddrinfo. I guess getaddrinfo from libc should respect NSS.

I used go 1.13 for compilation. Here is the code how we compile skopeo: https://github.com/adorsys-containers/ci-helm/blob/70ed90496cc169c32652b6757e569fa249cfb0b6/images/3.2/Dockerfile#L8-L21

The DISABLE_CGO=1 version of skoepo works fine. I use skoepo multiple times in different CI/CD pipelines on different projects. None of them had issues.

None of them work well enough

What not working well enough? Could you explain this more? I would like to understand. I didn't see the limitations.

Edit:

It looks like the make binary-local DISABLE_CGO=1 command doesn't build a pure static build:

bash-4.4# ldd /usr/local/bin/skopeo
	linux-vdso.so.1 (0x00007ffdffa73000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe910e09000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fe910a47000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fe912a48000)