Subject: Re: [boost] [all] Request for out of the box visibility support
From: degski (degski_at_[hidden])
Date: 2018-08-21 06:59:43
On Tue, 21 Aug 2018 at 09:23, Gavin Lambert via Boost <boost_at_[hidden]>
> 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
> > 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
> > 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.
Thank you for that write-up, I'll print and hang in bath-room :-).
-- *âIf something cannot go on forever, it will stop" - Herbert Stein* *âNo, it isnât truth. Truth isnât truth" - Rudolph W. L. Giuliani*
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk