Use CGO_ENABLED=0

[RealOrangeOne]

Fixes #295

Might fix #338

Also impacts #48 and #68

Naive attempt to create statically linked binaries, suitable for dstros like Alpine. Unlike previously, binaries now execute on Alpine.

Binary still appears to execute and connect to tunnels fine on Arch.

$ file nebula
nebula: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, Go BuildID=-XXX, not stripped

[CLAassistant]

All committers have signed the CLA.

[wadey]

I agree with this change, but only for linux builds. I think cgo does some things on darwin, windows that might be necessary there. The only thing that CGO does for us on linux is hostname lookups, but I don't think that should be an issue for most people. The power of having repeatable builds by disabling CGO would be very nice.

I wish it was easier to find a definitive list of the drawbacks for disabling CGO for each OS. Do you know of a good reference?

Do you think you could change this to only disable CGO on linux builds?

[RealOrangeOne]

A quick google search yields no really useful references other than "Where Go calls C". This is a bit of an interesting read.

I don't have access to a windows or macOS machine to try this patch out, but perhaps instead we should test this on windows and macos to see if it's better / no worse? Using the same compiler flags for each OS is probably a good thing, especially if that 1 OS is the one most of CI runs against.

Alternatively, perhaps instead specifically using netgo is an option (go build -tags osusergo,netgo). I'll give that a try this evening to see if that also solves the issue without completely disabling CGo.

[RealOrangeOne]

@wadey I found a simpler way. By explicitly using netgo explicitly instead of the cgo implementation, we keep the benefits of using cgo for some things, but with the cross-platform benefits.

I think I prefer this approach?

[wadey]

I just did some reviewing of the stdlib for everything using +build cgo, and now I'm pretty convinced that disabling CGO won't break anything. It seems pretty clear that the only two things the stdlib uses for CGO are the net and user cases, and we don't care about the user cases at all.

So now I'm on the side of lets just disable CGO like your original PR here, but I want to think a bit more.

[RealOrangeOne]

I know little about Go's internals, but yeah I do kinda prefer the cgo approach, that's also how Hugo does it.

I'll leave the branch as-is for now. Think and I can revert if needed.

I'm really keen to get this merged and shipped ASAP, as it'll help out a lot of platforms!

[wadey]

I've updated this PR to just set CGO_ENABLED=0, which I think is the better option. I have been testing with this and see no issues.