Linux amd64 build could potentially be fully static

[johnjelinek]

I'm not sure what dependency I'm missing, but it doesn't on alpine 3.2 for me.

[AudriusButkevicius]

whats alpine, also define doesn't run.

[calmh]

I'm guessing this:

Since alpine linux [...] use musl instead of gnu libc your golang binaries will not work inside alpine.

(http://www.blang.io/posts/2015-04_golang-alpine-build-golang-binaries-for-alpine-linux/)

I see that as a quirk in Alpine; someone who uses it needs to create a build for it.

[johnjelinek]

Huh? Build a static binary like in your link: CGO_ENABLED=0 go build -a -installsuffix cgo and then deploy everywhere.
On Dec 6, 2015 3:58 AM, "Jakob Borg" notifications@github.com wrote:

Closed #2555 #2555.

—
Reply to this email directly or view it on GitHub
#2555 (comment).

[johnjelinek]

@calmh: I think the quote you're referencing won't matter if you build a static binary to deployed everywhere.

[AudriusButkevicius]

Well I think there are reasons why we don't build a static binary.

[johnjelinek]

Can you please elaborate?

On Sun, Dec 6, 2015 at 3:03 PM, Audrius Butkevicius <
notifications@github.com> wrote:

Well there are reason why we dont build a static binary.

—
Reply to this email directly or view it on GitHub
#2555 (comment)
.

[AudriusButkevicius]

I think if we provide a fully static build, that potentially raises the bar of what's the minimum requirements required to run it (I think it's something todo with SSE instructions, but not sure how that fits into the static build question), but @calmh knows better.

[calmh]

So my reaction was the same, and I've been doing a bit of digging. The main thing we lose with a static build is access to the OS resolver library. This is an issue on Windows and Mac where somewhat exotic name lookup techniques are commonplace. On Mac we also lose access to the certificate store, which is critical. This is why we have native builders there.

However it doesn't seem like we lose anything relevant on Linux so we could potentially go fully static there. The 32 bit build already is, because it wants to run on peoples crappy NAS distributions that have libc from the 19th century or thereabout.

[johnjelinek]

Ya, I was meaning static just for the linux binaries, not for all
builds/platforms.
On Dec 8, 2015 1:16 AM, "Jakob Borg" notifications@github.com wrote:

So my reaction was the same, and I've been doing a bit of digging. The
main thing we lose with a static build is access to the OS resolver
library. This is an issue on Windows and Mac where somewhat exotic name
lookup techniques are commonplace. On Mac we also lose access to the
certificate store, which is critical. This is why we have native builders
there.

However it doesn't seem like we lose anything relevant on Linux so we
could potentially go fully static there. The 32 bit build already is,
because it wants to run on peoples crappy NAS distributions that have libc
from the 19th century or thereabout.

—
Reply to this email directly or view it on GitHub
#2555 (comment)
.

[calmh]

The linux builder now builds statics. Lets see how that works out.