They are. Static linking may be okay for small and simple libraries, but as a user, i do not want multiple versions of a complex library linked inside applications, each with slightly different behavior. And i do not want to upgrade all applications if there is a bug in, say, libpng or libfreetype.
> And i do not want to upgrade all applications if there is a bug in, say, libpng or libfreetype.
I don't think many people have problems with the idea that core system libraries could be dynamically linked. But Linux distros take this to a ridiculous extreme. I absolutely do not care if a bug in libgmp means my package manager updates the 2 apps I have installed that use it instead of 1 library.
Would be really interesting to see some actual stats about this though. How many library projects do people have installed that are depended on by more than say 3 apps? I'm guessing it's under 100.
I think that's the approach Flatpak takes with it's "runtimes" and it seems like a very sensible one.
Even if you just use 2 apps that depends on 1 library, there may be tens or hundreds of such apps in the distribution repository (which is, btw, the case for libgmp). A bug in such library would force distribution maintainers to release new packages for all these applications, instead of just one.
I think that if the library is independent upstream project, then there is no reason why it should not be dynamically-linked independent package in distributions.
Doesn't matter. You'd rather update X separate packages (of unknown size & potentially different maintainers or update policies) to fix 1 bug in a library they all happen to use?
Shared libraries are a good thing, period. Implemented poorly? Fix that instead, rather than include everything & the kitchen sink in every single app.
