#static linking

I've been thinking about this on and off for years, and it seems a tad stale - wisdom from an earlier time which does not apply as much anymore.

If we assume someone has to manually compile every binary from source, that fits. This is the one situation in which I personally felt that benefit. When I was manually going through the cycle of download -> `./configure ...` -> `make` -> `sudo make install` and so on for a bunch of software on the Nokia N900. I learned a lot from this, but otherwise I'd say it was a waste of my precious finite life. If I had to recompile everything again for a fix to my libc or TLS libraries or something else that was used by a bunch of software, I'd have a bad time. Similarly, on that weak low-powered hardware, it would take a lot of time.

But let's assume proper automation. Let's assume that installing upgrades is a matter of running a single command, or even entirely automatic. As it is already for most users on most systems. In that case, static inclusion of libraries doesn't get in the way of upgradability from a manual effort perspective. All the binaries that use the library can be rebuilt.

Let's assume a typical system where a trusted build server does the builds, and most devices download pre-built libraries from those servers. As it is already with most package managers on most systems that most users have. Then static inclusion of libraries into binaries doesn't even affect upgrade time much, because the rebuilding of all those binaries that use a library is amortized and done out-of-band by the build system.

Let's assume some modest optimizations: static linking doesn't have to include the whole library - it can include just the parts that are used; whole program optimization means that those included parts might be inlined and simplified to just the cases in the logic that are actually used; if after all that there is still a lot of identical library code in binaries, downloads can use compression over all the binaries together. So static inclusion of libraries doesn't have to substantially increase download sizes for installs and upgrades.

(If it is commonly the case that large chunks of code are frequently duplicated between binaries, we can even design a package system where those duplications are detected and recorded, so the package manager doesn't have to download those chunks of a binary if it knows that it can copy it from another binary that is already locally available. I don't know how often this is an optimization worth making, but if I had to guess, you'd have large duplications in multiple binaries of code from libraries implementing network protocols, cryptography, and GUI frameworks - code which is complex or has to handle a lot of possible situations from the external world.)

Disk and memory space tends to be huge nowadays, so even if after whole program optimization programs are still big, that's not the same dire problem it once was. If benchmarking proves that it is, however, then splitting into dynamic libraries can be a separate optimization step! Tooling could identify common chunks of code in multiple statically compiled libraries, and pull them out into common files which are then dynamically linked at runtime.

In Visual Studio, go to the project Properties.

Change Configuration to Release.

Go under Configuration Properties | C/C++ | Code Generation

Look at the Runtime Library setting.  If it's set to: Multi-threaded DLL (/MD) Change it to: Multi-threaded (/MT)