[arp242]

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.

[account42]

> 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.

[arp242]

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.