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