Re: [boost] Including a system link library for every test, but only on mingw-w64 builds?

Subject: Re: [boost] Including a system link library for every test, but only on mingw-w64 builds?
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2017-11-07 00:23:28

On 11/07/17 02:25, Robert Ramey via Boost wrote:
> On 11/6/17 1:51 PM, Andrey Semashev via Boost wrote:
>>
>> Autolinking (and the tool implemented in config/auto_link.hpp) has 
>> nothing to do with exporting or importing symbols. For that you use 
>> BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_IMPORT, which are also provided by 
>> Boost.Config but are not part of the autolinking.
>>
>> You can see that gcc does not support autolinking from auto_link.hpp:
> 
> OK
> 
> But the msvc autolinking decorations resolve to 
> BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_EXPORT.

It works backwards.

1. You mark the symbols you want with 
BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_EXPORT, depending on whether your 
library is built or used.

2. You define a few config macros and #include 
<boost/config/auto_link.hpp>. This is a no-op when your library is built 
and expands into pragmas to bring your library to the linker when your 
library is used. It does not decorate any symbols.

The two steps are independent; you can do one thing without the other. 
Just doing #2 won't do #1 for you and vice versa. You do both steps on 
all platforms, but #2 is a no-op everywhere but Windows.

> So msvc "automatically" 
> implements limited visibililty.  This can and I think is meant to 
> support generated limited visibility with gcc/clang compilers while 
> supporting autolinking as well for msvc.

MSVC (or rather, Windows) doesn't support visibility because Windows 
runtime linker works differently. I'm not sure if gcc's 
__attribute__((visibility)) does anything on Windows, probably nothing.

BOOST_SYMBOL_* macros expand to dllexport/dllimport attributes, which is 
something different than visibility. Instead of just making the symbol 
visible, it alters its mangling; dllexport also generates a stub for the 
symbol in the .lib file that is to be consumed by the users of the .dll.

> If one aims to make a portable library which supports limited visibility 
> with gcc/clang and autolinking with msvc, you'll be dealing with all of 
> this at once.
> 
> One solution is two avoid using limited visibility for gcc/clang and 
> your life will be easier.  But if your library is large - like the 
> serialization library, users will complain about the size of shared 
> libraries.

Using hidden visibility is fine and even encouraged. Since Windows 
doesn't support visibility but doesn't export any symbols by default, 
the behavior there is actually quite close to hidden visibility. But you 
have to be careful to mark certain symbols visible with 
BOOST_SYMBOL_VISIBLE, like exception types and the types you plan to use 
with typeid/dynamic_cast. This is a no-op on Windows and is easy to 
forget if you don't test on other platforms. 
BOOST_SYMBOL_EXPORT/BOOST_SYMBOL_EXPORT will still have the intended 
effect on all systems, Windows and not.