That is ok if you're just dealing with the upper layer of code, i.e., the final application. Then statically linking can very well be the best solution. But if

That is ok if you're just dealing with the upper layer of code, i.e., the final application. Then statically linking can very well be the best solution. But if you're building an operating system or distribution and do not want to recompile the whole of it (and let users download and reinstall the whole of it) each time you fix a bug in a core library, then static linking becomes pretty quickly a big pain. More or less the same happens with C++ header-only libraries, which are basically uncompiled static libraries. They are very nice and possibly allow strong optimization, but are rather painful to handle in a distribution. > Plus with a static binary, if you really care about order of loading/unloading etc (which you ideally shouldn't) its trivial to manage with a custom linker script. Why? It seems to me rather sensible to deinitialize resources in the opposite order in which you initialized them. This way the time span of different resources are contained each within the other instead of just overlap. When using RAII in C++ (which is basically just atexit on a finer grain) it often makes sense to have this requirement.