3 ms·
The old reason for shared libraries was to share memory/cache and not waste disk space. That's not gone, but maybe it's less important than it used to be. The
by zrm 2y ago
The old reason for shared libraries was to share memory/cache and not waste disk space. That's not gone, but maybe it's less important than it used to be.
The modern reason is maintenance. If 100 apps are using libfoo, in practice nobody is going to maintain a hundred separate versions of libfoo. That means your choices are a) have hundreds of broken versions nobody is maintaining spread all over, or b) maintain a small number of major releases forked at the point where compatibility breaks, so that every version of 1.x.x is compatible with the latest version of 1.x.x and every version of 2.x.x is compatible with the latest version of 2.x.x, and somebody is maintaining a recent version of each series, so you can include it as a shared library that everything else links against.
But then you need libraries to limit compatibility-breaking changes to once or twice a decade.
- JackSlateur 2y agoThe maintenance reason is not really serious: you can maintain one version of the library and still do only static binaries: when you need to upgrade the library, you recompile it, and relink every binaries that uses it. The whole process is slower that doing dynamic linking, but still quite fast. It does require tooling, though.
- zrm 2y agoIf you're only maintaining one version of the library that everything uses then what do you get from static linking? The reason people want static linking is to be able to use all different versions of the library, which is what causes the maintenance problem.