Add static build support

[CajuM]

This will increase the portability of the binary and is necessary if we want to bind-mount crio-lxc as a container's init

[tych0]

Since we do bind mount crio-lxc in to be init, is there ever a case where we don't want to build in this configuration? Seems like it should be the default. So why not just,

index 92d7d0d..93174ba 100644
--- a/Makefile
+++ b/Makefile
@@ -5,7 +5,7 @@ TEST?=$(patsubst test/%.bats,%,$(wildcard test/*.bats))
 CRIO_REPO?=~/packages/cri-o
 
 crio-lxc: $(GO_SRC)
-       go build -ldflags "-X main.version=$(COMMIT)" -o crio-lxc ./cmd
+       go build -ldflags "-X main.version=$(COMMIT) -extldflags '-static -lseccomp -llxc -lcap -lselinux'" -o crio-lxc ./cmd
 
 # make test TEST=basic will run only the basic test.
 .PHONY: check

But better yet, can we do something like is suggested in this bug:
golang/go#26492 and add a static_build tag to lxc, so users can choose?

[tych0]

Sorry, add a static build tag to go-lxc*

[CajuM]

pending lxc/go-lxc#128

[hallyn]

The go-lxc PR is now merged.

[hallyn]

No, seriously - why not use stacker here?

Though really, simply telling people the build dependencies should also suffice. Think of it this way: This binary will be statically linked with all the trash in whatever distro+release you decide to specify in the stackerfile. I've already chosen what I think I trust on my systems, and now you're going to hand me something linked against something completely different, which is then going to run privileged?

[CajuM]

I wouldn't use stacker in this project, for now, as it's absent from the machines of most potential developers. If I do a google search right now for projects using stacker, I won't find anything. Now would be a good opportunity to gain users for stacker, but at the expense of crio-lxc

I updated the PR to always use static_build for a local build. For a in-container build where the developer doesn't want to bother with the dependencies it will use Alpine.

[hallyn]

So we've pretty much guaranteed that local builds will fail.

I'm not sure what our best move is here. We can leave that as is and work toward centos and ubuntu providing the required static libs. Or we can make 'make foreign' the default target after all. We can make the local build an optional one, and maybe make it a dynamic build? The point of that would be to give quicker build errors during development.

Thoughts?

[hallyn]

I'll merge as is for now, the rest (if therei is a rest) can be a new PR.