Statically linked binaries? about lilliput

[brian-armstrong-discord]

Sorry, I'm not quite sure what you mean by this. If you build with lilliput, the Go binary you get should only link libc dynamically presently. Can you give me more specific information on what isn't static in your situation?

[seeekr]

I should have added more information. Specifically I'm trying this:

Let's say this is my main.go file:

package main

import (
	"github.com/discordapp/lilliput"
)

func main() {
        // just so we can import lilliput...
	lilliput.NewDecoder(nil)
}

I'm trying to build a static binary like this:

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

(I did try other command lines, with and without a bunch of these flags; did not find a definitive source of truth for how to do this.)

And then I'm getting these errors during compilation:

# github.com/discordapp/lilliput
../../../github.com/discordapp/lilliput/lilliput.go:26:13: undefined: ImageHeader
../../../github.com/discordapp/lilliput/lilliput.go:41:14: undefined: Framebuffer
../../../github.com/discordapp/lilliput/lilliput.go:48:12: undefined: Framebuffer
../../../github.com/discordapp/lilliput/ops.go:43:16: undefined: Framebuffer

With the C/C++ libraries being used by lilliput, I was doubting that it would be possible to create a fully statically linked binary (without too much effort), so that's why I thought I would ask here if there is a way.
Hope this makes more sense now!

Thanks!

[brian-armstrong-discord]

Ah, I see. Sounds like you are trying to get around including libc then.

To me, the idea of a unix system without libc sounds like madness. But I gather Docker tends to do things in strange ways. If you really want to do this, you'll need to build each of the libs packaged with lilliput with static libc linkage. This is going to require going through each step in the build-deps-linux.sh file and changing the config to using your chosen libc. You'll need to dig around and find out how people have built OpenCV and ffmpeg with static libc, amongst the other various deps here. And then on top of that, as you've done, you need to convince Go itself not to use its bits that depend on a shared libc like the networking portions (e.g. use netgo). (If you're getting the impression that no sane system would ever omit libc... you are correct).

I don't know that you'll actually need the bit about ldflags - I think once you've made these changes, you'll be set. CGO_ENABLED=0 is basically nonsense in this context since it disables Go's ability to build C and C++.

Good luck, and let me know if you have other questions on the way.

[brian-armstrong-discord]

Actually, after reading a bit more, it seems what that bit with ldflags is trying to do is pass -static to Cgo. That definitely won't work here on its own since so many deps are already built targeting dynamic libc, but it does point to a good place to start. If you just add -static to CFLAGS in build-deps-linux.sh, that might just work. And you will actually need -ldflags '-w -extldflags "-static"' for lilliput, since the small amount of binding here uses some libc as well.

[nxnfufunezn]

yes just do

GOOS=linux GOARCH=amd64 go build  -ldflags '-w -s -extldflags "-static"' -a -installsuffix cgo -o main

and it should work