I honestly don't really care how "unreliable" you think shared libraries are, using entirely static linking is how we get gigantic 500MB monoliths that waste disk space and RAM, don't integrate with the rest of the system properly due to mismatched library versions, and also don't get security patches from the system unless you manually update the binary itself.

Static linking may be "easier", but as programmers, it's our job to use the *right* solution, not just the easiest one.

@keith https://drewdevault.com/dynlib thoughts?

@makeworld yeah but I don't think anyone has statically linked OpenSSL or the like into highly popular programs yet. if that was the case we'd be fucked

@keith @makeworld Static linking *SSL programs isn't too uncommon. If you want to use boringssl or quictls instead of openssl in a program to take advantage of a feature like QUIC or ECH but your distro uses openssl, then the cleanest solution is to statically link the alternative libraries in.

Static linking can also help squeeze out some performance if you do PGO and LTO. I managed to shave off a few framedrops from mpv+ffmpeg this way.

It can also *save* disk space in some situations: if a program doesn't use an entire library, only the relevant bits get linked into a static binary. Again, PGO can really help reduce binary size here. If you compare a standard mpv package with all its ffmpeg/libass and encoder/decoder libs with a 44mb statically-linked PGO'd mpv, it's not much of a contest. A statically linked mpv and mpd on my system actually use less disk space than their dynlinked alternatives (including shared libs).