[kev009]

In case it's not obvious: if you static link to a library, say libpng, and a vuln hits, every binary that linked to libpng potentially needs to be rebuilt and distributed.

If the OS has rigid dependency tracking (maybe source distros like Gentoo, or a cryptographically tracked binary distribution like freebsd-update), maybe you can live with that.

So there's some trade off of "dll hell" for binary hell, and perhaps some other security advantages to dynamic libs. IMHO shared libraries are pretty well understood now days and static linking should be avoided unless you have a very good reason.

[qznc]

That vuln problem works the other way round as well. When a new libpng vulnerability is introduced all executables using the shared library are affected, while static-lib users with an older version are fine.

[microtonal]

But in general, all binaries in a distribution are compiled against the same version of a library, namely the one that is distributed with it. I don't see that changing in a distribution that was fully statically linked.

Even in the unlikely case where binaries are statically linked against different versions of a library. You'd still have to check against which version each binary is compiled.

Of course, you also gain in security, since all kind of library preloading attacks are not possible anymore.

[default_name]

Many applications started shipping with all neccessary libraries, that's like taking disadvantages of static and dynamic linking combined. At least they can adhere to GPL...

[ksk]

There are already ways to mitigate that. One example would be to use mandatory access control to 'host' the library in a separate process which is stripped off of all unnecessary rights/privileges.