On 08/21/2018 05:35 PM, Gavin Lambert via Boost wrote: On 21/08/2018 19:04, Olaf van der Spek wrote: IMO dynamic libs make sense if they're managed by the system, if you have to distribute / install them yourself chances are they're not going to be shared anyway. If your application consists of multiple separate executable binaries, then you might still want to distribute a library that they all share dynamically, even if it's private. And it is still possible to install libraries system-wide, although that tends to be more frowned on nowadays due to long years of people doing it wrong and installing something that breaks other applications. Full static, or something that's not easily possible today (AFAIK), building the library files directly as part of your project, ensures you always link to the same code and in the latter case ensures the lib is build with exactly the same settings as your project. The latter is like header-only libs.. Yes, although the latter often brings its own headaches with the build environment (include paths and defined symbols, mostly), which is probably why it's not done as often. And also people often want to be able to compile a library once and then just use it rather than having to recompile it periodically. Static CRT is mostly (only?) an issue on Windows isn't it? If only MS / Windows itself would take care of installing it. I think you have some wires crossed. The static CRT is compiled into an application, so by definition doesn't require installation at all. And the dynamic CRT is already installed as part of Windows -- every Windows version always includes all the previously-released CRTs bundled into it. But until they invent a handy time machine, they can't bundle the runtimes that are released after the OS is released. Sometimes they get included in Windows Update, sometimes not (traditionally only security fixes were included, not general feature releases). But in general if you're releasing some software that uses a runtime newer than the oldest version of Windows you're expecting it to run on, then you need to include the runtime in your installer, just in case. Or use the static CRT instead. This is not a Windows-only issue either -- it's just more common to use the latest Windows dev tools than it is to use the latest gcc/clang/stdlib on Linux, since the latter require complex building from source. And then if you do that you would again either have to use the static runtime or distribute a dynamic runtime along with your binary if you expect it to be able to run on a system that only has the older runtime installed. (Again, Linux seems less prone to this in general only due to the culture of compiling from source rather than distributing binaries, unless using binaries precompiled and distributed by the system vendor.) This is getting a bit off-topic anyway. All of these technical issues requiring so much effort and expertise now and for the foreseeable future. I would prefer to at least have the choice of pure header only for all libs, because I don't care how long my compile takes.