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: Robert Ramey (ramey_at_[hidden])
Date: 2017-11-06 23:25:47

On 11/6/17 1:51 PM, Andrey Semashev via Boost wrote:
> On 11/07/17 00:39, Robert Ramey via Boost wrote:
>> On 11/6/17 12:48 PM, James E. King, III via Boost wrote:
>>> Is BOOST_AUTO_LINK supposed to work on mingw-w64 builds with gcc?  I'm
>>> guessing not since I believe this is a MSVC concept, so I am looking 
>>> for a
>>> bjam recipe that will allow me to add the link library bcrypt.lib to 
>>> all of
>>> the tests in a project's test directory if the build is on a windows 
>>> system
>>> and not using msvc toolset.  Are these any examples out there?
>>
>> autolink isn't an just a msvc concept anymore.  The boost autolink 
>> supports two functions:
>>
>> a) creating and linking to a library with the correct abi
>> b) making the symbols to be exported from the library and imported 
>> into the application visible.  This is not supported under the name 
>> "visibility" for gcc and clang compilers.
> 
> 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.  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.

It has gotten slightly sticky with mingw which is a "windows" platform 
with DLLS, autolinking etc but a gcc compiler.

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.

Robert Ramey