Re: [boost] [all] Request for out of the box visibility support

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]>
wrote:

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

Thank you for that write-up, I'll print and hang in bath-room :-).

degski
-- 
*“If something cannot go on forever, it will stop" - Herbert Stein*
*“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*