At least one C++ library that I rely on (that produces an incredible number of template instantiations in the object files) ultimately results in a 2 GB shared object file for the debug version (generating DWARF info for 300,000+ objects takes up a lot of space). The test suite for this project compiles and runs about 5,000 executables that link, in some way, to that giant shared object library. Statically linking the test suite would consume on the order of terabytes (I am not sure the exact number; I have never tried) of disk space which just is not feasible for a workstation, so dynamic linking is the only reasonable option. Dynamic linking also makes testing easier since I do not have to recompile tests as often.

That said, DLL hell is definitely real (as anyone who has ever used windows knows). Things are generally better (though not perfect) with OSs like Debian where dependencies are centrally managed across the whole system. In general, doing C++ development, I have found it advantageous to dynamically link: recompiling one library does not necessitate recompiling everything that depends on it.

> Statically linking the test suite would consume on the order of terabytes (I am not sure the exact number; I have never tried) of disk space which just is not feasible for a workstation

I read complaints like this a lot. Have you ever tried using -ffunction-sections -fdata-sections and --gc-sections as in :https://elinux.org/images/2/2d/ELC2010-gc-sections_Denys_Vla...

I find static linking to take up far less disk space when done properly, but I keep seeing comments like this.

MSVC linker also supports removing unused functions/data from the output binary: https://msdn.microsoft.com/en-us/library/bxwfs976.aspx. These can be applied irrespective of compiler optimizations, so you should still be getting good PGD debug symbols.

Haven't tried it personally, but it's worth a try.

Why don't you run your test suite with dynamic linking, then? I've certainly worked at large, successful companies with enormous C++ codebases where unoptimized tests are run with dynamic linking and production binaries optimized, stripped, and linked statically.

These days I mostly work in JavaScript, and say what you will about NPM, at least it provides a consistent, reliable, central strategy for retrieving and organizing external dependencies (assuming you haven't just built them into your bundle). The same is true of Maven for Java, to some extent. It seems like at least in Linux, the package manager will get your DLL's for you and coordinate all that, but as far as I can tell there's nothing similar for Windows? Do Windows programs that rely on DLL's just have to manually check what's already there, whether it matches their needs, and copy files over during the installation process if necessary?

I develop small to medium size Windows applications. It's much easier for me to simply put all the DLLs I need in the installer. Just copy everything into the installation directory. Since Windows looks in the immediate directory first, that eliminates most potential conflicts. There are some things you might install onto the system like C++ redistributables, but even recently I have just started copying those DLLs into the installation directory too. Most people like this because the application directory is fully standalone and can be copied around from PC to PC.

Which totally defeats the purpose of dll's, right? I'm not judging; this just seems like a pretty condemning argument against the practice as a whole

It's not. DLLs also provide a way to share compiled code between programming languages that are not binary compatible.