Hacker News Reader

Comment by ashishmax31 | Hacker News Reader

I would think so. Can anyone eli5 why statically linking binaries is a big deal? Even light weight container oriented linux distributions like alpine ship with musl. In which scenario would it find it use cases?

View on HN

Massively simplifies the build process, especially for cross-compilation. You can just build the binary, copy it over and run it, without having to ever touch containers, or having to worry about sysroots.

You can go ahead and do the following on your Mac:

    GOARCH=riscv GOOS=linux go build

to build a binary that just runs on Linux on RISC-V.

One advantage is that you need to worry less about versions; if I build a dynamic library that uses a feature from GNU libc 2.30, and someone tries to run it with GNU libc 2.23 then they will get an error.

These versions are not chosen at random: I ran in to this issue with people trying to run my binary on Ubuntu 16.04 (LTS release), which was solved by linking it statically.

Also, people may use musl libc, and while it has some compatibility with GNU libc this is far from complete.

So in short, linking it statically means it will work for the largest amount of people with a minimal of fuss for both the person building the binaries, and the people running them.

As people have mentioned, these issues are less present on non-Linux systems.

> which was solved by linking it statically

You could also have linked against glibc 2.23 or 2.22 or older instead of bloating your binary.

But that's a lot more effort, and who knows if someone is still using a CentOS or whatnot with an even older version. And it still won't work for other libc implementations.

Adding an extra megabyte or so is a reasonable trade-off, with no real other downsides. It's not that large – smaller than many websites.

Some have the viewpoint that static linking allows for what is essentially dependency pinning of binaries.

Reply on news.ycombinator.com