3 ms·

Doesn't generalized static linking makes fixing security holes a maintainer's nightmare? What about keeping libraries dynamic, but allowing different versions

• twblalock 8y ago
  The problem for Unix is that C dependencies don't work that way, and it would take a huge amount of effort and culture change in the C ecosystem to make something like that happen. It would probably involve more effort than just statically linking the binaries. If this worked, developers would have no incentive to upgrade library versions that are working properly. The number of programs on your system that share the same library version would decrease over time until most of them use different versions, so you will miss out on the advantage of dynamic linking anyway -- updating a library would only fix security holes in a subset of your programs. You might as well just statically link everything and call it a day.
  • Ace17 8y ago
    > until most of them use different versions, so you will miss out on the advantage of dynamic linking anyway -- updating a library would only fix security holes in a subset of your programs. You might as well just statically link everything and call it a day. Please don't. Especially if I don't have your source code. A reduced amount of binaries to upgrade is only the tip of the iceberg. Even if I have 10 programs using 10 different versions of the same library, dynamic linking is a better choice than static linking. Because it allows security upgrades, independently of any collaboration with the vendors of these 10 programs.