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

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