"The trouble with shared libraries is that they seem at first quite reasonable, and indeed at a fairly abstract level, it seems irrational to be more opposed to them than any other form of sharing, such as shared text, but the mechanics of linking and sharing (especially on current processors), and of configuration control, have so many hard facts that the simplicity of the original is quite lost. Having experienced several variants, I find it now saves time just to adopt the irrational position from the start. I think I'd rather have (say) mondrian memory protection than either shared libraries or the VM crud they keep adding to chips and systems." -- Charles Forsyth Dynamic linking implies dependency. Dependency is a synonym for modularity. If your modules are not controlled at runtime then neither are your dependencies; and likely as not, neither are their dependencies, and so on. Static Link Everything Together! Attaining (very minimally) some (or at least one) of the advantages of Multics style dynamic linking by static linking everything, not just alone per program but, together all programs into one big binary. Leveraging the power of the (static) linker and the VM pager to gain a wee bit of the advantage of true "dynamic" linking. Issues with building modern code for static-only environments: The biggest problem I have with building applications for environments where I want everything to be static linked is that compiler toolchain authors have tried to make things "simple" for users by allowing the user to omit necessary dependent libraries from linker commands when the runtime is being linked dynamically, but yet still require these libraries to be specified when the runtime is being linked statically. This means that lazy developers who never bother to even try to test their applications in a static linked environment will not provide sufficient configuration mechanisms to allow a static link to proceed without first modifying the build instructions. The second biggest problem is that those lazy developers who fail to appreciate the need to support static linking will almost certainly also fail to properly understand all of the implications of the object and library dependency tree and as a result they will never even notice any conflicts or incompatibilities in those dependent objects. This situation is made infinitely worse with versioned symbols in DSOs. Toolchain developers could provide default checks and warnings about some missing libraries and conflicts in inter-library dependencies, but of course they almost never do, and runtime loaders will make automated choices which might appear to work in the developer's environment but which will inevitably cause problems in the end user's environment -- problems which would be caught quickly and eaisly at link time if the developer properly tested static linking. Sadly also because of the attitudes we derive from living in a world of all too much proprietary software and belief that end users cannot ever manage to use software construction tools (even though we could easily automate and hide their use), we end up with developers believing that they need to provide support for dynamic runtime plugin modules, even in sutuations where permanent choices are made for the target environment at install time. The result is we end up with a shaky house of cards that's all to vulnerable to exploit by untrusted third parties. And then we have the disaster that is Solaris 10.... (and OSX or macOS) Some similar opinions: http://blogs.sun.com/rvs/entry/what_does_dynamic_linking_and https://web.archive.org/web/20091025040228/http://blogs.sun.com/rvs/entry/what_does_dynamic_linking_and "dynamic linking does not deliver on any of its promises" "wasting precious CPU cycles on position independent code" http://bender.eugenics-research.org/harmful/software/dynamic_linking/ http://port70.net/~nsz/32_dynlink.html http://harmful.cat-v.org/software/dynamic-linking/ "In general, they are used for security checks, so if you use them you want to link them static." -- phk (1994-07-24, describing his libmd import to FreeBSD) "I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications." -- John Carmack "The reason why dynamic linking was invented was not to decrease the general executable sizes or to save memory consumption, or to speed up anything -- but to allow changing code during runtime -- and that's the real purpose of dynamic linking, we must not forget that!" -- paraphrased from suckless.org "All the purported benefits of dynamic linking (aka., ‘shared libraries’, which is a misnomer as static linking also shares libraries) are myths while it creates great (and often ignored) problems." -- from http://harmful.cat-v.org/software/dynamic-linking/ "Both performance and security are seriously harmed by dynamic linking, but the damage caused by the huge complexity created by dynamic linking is extensive in almost all areas (the term ‘dll hell’ is just one example of the many hells created in dynamic linking environments)." -- from http://harmful.cat-v.org/software/dynamic-linking/ Paged virtual memory was a mistake. Dynamic linking (or shared objects in general) is unconscionable. It is an embarrassment that either of these technologies made it into the 21st century. -- (https://lists.nycbug.org:8443/pipermail/talk/2022-March/018485.html)