Shared Libraries Considered Harmful? - fordsfords/fordsfords.github.io GitHub Wiki

Shared Objects (.so files) ... HUH! ... what is it good for? (Absolutely nothing?)

Linus seems to think so.. When he says, "...they also add lots of unnecessary dependencies and complexity, and almost no shared libraries are actually version-safe... he's talking about Dependency hell (a.k.a. DLL Hell).

But, as Linus pointed out, shared libs are sometimes used as an extension model. That's what NSS and iconv are basically doing.

A slight variation on that is having optional dependencies on third party packages. E.g. Ultra Messaging uses dlopen()/dlsym() to access OpenSSH if the user configures it. The alternative might be to have the Store be built by the customer with the desired features specified at build time. That would allow OpenSSH to be either included or not. As security fixes are made, the user would have to rebuild with the fixed version rather than just swapping in the new shared object. (Of course, that's off the table for closed-source software, but I wouldn't expect Torvalds or Stallman to make our lives easier.)

Another way that UM uses dlopen()/dlsym() is to access the recvmmsg() function. Several years ago, we had customers using older kernels that didn't support recvmmsg() and other customers with newer kernels that did. If you run on an older kernel and you try to use the feature that calls recvmmsg(), we print a nice error. I'm not sure that is possible with static links, although as above, we could push it onto the customer to rebuild our product with features specified at build time.

According to this Stack overflow thread, static executables were dying in many Linux distros, but has had a resurgence of interest.

Finally, I will note that static linking doesn't necessarily solve all dependency hell issues. I might use two third-party packages, both of which use a third package. But the two that I use require different and incompatible versions of the third package. Static linking doesn't solve that.