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-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.