$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
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