Subject: Re: [boost] [all] Request for out of the box visibility support
From: Jeffrey Graham (jeffrey.graham.traclabs_at_[hidden])
Date: 2018-08-22 15:28:45
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
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
/ 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
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk