Boost logo

Boost :

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

It works backwards.

1. You mark the symbols you want with
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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at