Re: [boost] [all] Request for out of the box visibility support

Subject: Re: [boost] [all] Request for out of the box visibility support
From: Gavin Lambert (boost_at_[hidden])
Date: 2018-08-22 00:35:15

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.