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 05:02:25

On Tue, 21 Aug 2018 at 07:45, Gavin Lambert via Boost <boost_at_[hidden]>
wrote:

> I've never used vcpkg, so I can't really speak to its choices, but
> whenever you create a new project in VS (regardless if it is an
> executable, static library, or dynamic library), it will select the
> dynamic CRT by default, because this is the safest choice in all cases.
>
> And a cursory glance at the vcpkg repository shows that this script:
>
>
> https://github.com/Microsoft/vcpkg/blob/961cd9effd9a5230f211875bb0e9a6773e0e3fab/scripts/cmake/vcpkg_check_linkage.cmake
>
> attempts to prevent you compiling a dynamic library while linking to the
> static CRT.  (I don't know how well it is actually applied; perhaps I'm
> misreading something.)
>

Yes, that's correct, by default a dynamic library links to the dynamic crt
and a static library will be statically linked to the crt. There are some
cases/packages where this is overridden however, where the dynamic crt
linking is enforced.

> As I said before, there is no problem with linking to the static CRT if
> you are *only* using static libraries.
>

I re-read and see that now, this is what I always try to do, which
pre-cludes using intel-tbb, which is a bit of a bummer.

There is also less problem if you are only using DLLs that practice
> strict memory segregation (eg. using an agreed memory allocator for all
> exchanged objects, such as the COM or Shell allocators), or ensuring
> that objects are only ever allocated or deallocated on exactly one "side".
>
> It's a lot harder (though not impossible, with very careful use of smart
> pointers and allocators) to achieve this segregation with C++ libraries.
>
> (Having said that, this only discusses one aspect of library
> duplication, that of separate heaps.  There can be other issues such as
> duplicate singletons and other statics; these can also ruin your day,
> but are more library-specific.)
>
> Other "shared" CRT state (locale, exceptions, standard I/O streams, etc)
> also won't actually be shared if you are using multiple static CRTs.
>

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.

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)

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*