[Wowfunhappy]

Yes, sign me up please! You don't necessarily need to go all the way down to statically linking libc, but if just about everything else could be included in the binary, that would be lovely.

We have come up with such convoluted solutions to this problem—Docker, nix, Snap, etc—when the simple option is sitting in front of us. And it works! On my Mac, I don't want to install homebrew or MacPorts—Package managers make me feel like I never know the state of my system—so when I need a command line tool, I try to either track down or otherwise compile (in a VM) a static binary. When I can find them, they work perfectly!

[enriquto]

You can link libc statically, it's probably smaller than the other stuff you use. If you are really worried about size you can use the musl which is quite smaller.

The only problem I have found with static linking is for programs that use opengl, that need to be linked to a specific version of the graphics drivers. If you try to statically link a program that depends on libGL, it may work for you with an nvidia chipsed, but then it will fail at runtime for somebody that does not have the same type of graphic card. I do not know of a clean solution for this problem, regarding static linking; but I would love to know.

[Wowfunhappy]

I'm not against linking libc statically, but the reason I brought that up is to preempt a counterargument I always see: what happens if a security vulnerability is found in libc, and just about every single program needs to be recompiled?

My response is either (A) so what, go ahead, it's worth the complexity tradeoff for static binaries, but also (B) you can link a tiny handful of core system libraries dynamically, and still reap most of the simplicity benefits of static linking.

The latter approach solves the OpenGL problem too. If there are real cases where users would need to swap that out, go ahead and link it dynamically. The goal needn't to remove all dependencies, but to avoid the quagmire of hundreds (or more) of nested dependencies.