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 04:45:08

On 21/08/2018 15:35, degski wrote:
>> This is why you're always encouraged to link to the runtime library as
>> shared -- because since it's a dependency of every other library, the
>> only time it's safe to use it statically is if you don't use *any*
>> shared libraries at all.  Otherwise you end up with multiple copies of
>> the runtime, and thus multiple separate heaps, and hilarity ensues.
> 
> This is I think not what happens in practice, in vcpkg f.e. creation of a
> static library will by default also imply that that library is statically
> linked to the run-time. I also do this when building Boost, while you are
> actually saying that that option/possibility should not even exist as I
> presume that the combination of a dynamic library statically linked to the
> run-time crt makes even less sense.

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

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

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.