Boost logo

Boost :

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

On 21/08/2018 17:02, degski wrote:
> I will make some notes of all this, because it seems highly relevant, not
> widely discussed and frankly quite a mine-field regardless of whether one
> opts to be fully dynamic or fully static.

Yep. I don't speak in any official capacity, just as one who has
experienced biJ.

> You are saying there are quite lot lot of caveats either way, what is your
> basic advice, dll's or static linking (static or dynamic crt?)? I would
> like to try and get to some rule-set, guidance principle (if even just for
> myself)

As a library creator, you don't really get to choose (unless you want to
force the user's choice by only supporting dynamic linking).

I don't think it is a safe choice for a C++ library to only support
static linking, unless it can make certain guarantees about its
consumers (eg. that there will only be one, or that its multiple
consumers will only be statically linked themselves). (Related:
Boost.Exception makes me nervous in that regard, though I haven't looked
into it.) I don't mean that it's always unsafe, just that it's a lot
harder, and thus easier to accidentally mess it up.

As an application creator, you have a bit more free rein to choose
whether to go all-static or all-dynamic (unless you're forced to use a
dynamic library).

Note that licenses can also force your hand; for example you can only
use an LGPL library if you dynamically link to it or if you use GPL or
LGPL yourself.

Using dynamic libraries is nice because they're more modular, and at
least in the case of an actually shared library can reduce system memory
usage. They can also aid patch deployment if you know you only need to
replace a subset of files, or for installing optional plugins. And they
usually Just Workâ„¢.

But they also increase the security attack surface of your application,
both due to exposing symbol names and addresses of corresponding code,
and because it's usually trivial to impersonate an external library.

Static libraries also have a possible advantage of compiling everything
into a single binary, which might make it easier to create a portable
application or one that otherwise doesn't require installation.

In ye olde bog standard user application I personally tend to default to
using shared libraries for everything (notably, also using
BOOST_ALL_DYN_LINK to help enforce this). However it might not be the
best choice when interfacing with a library like OpenSSL, for example.

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