Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at