James E. King, III wrote:

On Mon, Nov 6, 2017 at 4:03 PM, Steven Watanabe via Boost wrote:

...

The conditional would look like <toolset>gcc,<target-os>windows:...

That allows me to make a conditional <cxxflags> or <link> or whatnot, by appending it to the end.

How do I apply this to control whether a bjam directive (like [ run ... ]) is executed on a given platform?

You can use `<build>no` to disable something.

I would also like to use this technique to prevent a short benchmark from building and running in the debug variant.

In this case, for instance, `<variant>debug:<build>no`. (This is how `[ requires cxx11_constexpr ]` (for example) works; it returns either `<build>no` or nothing.)

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: // // Only include what follows for known and supported compilers: // #if defined(BOOST_MSVC) \ || defined(__BORLANDC__) \ || (defined(__MWERKS__) && defined(_WIN32) && (__MWERKS__ >= 0x3000)) \ || (defined(__ICL) && defined(_MSC_EXTENSIONS) && (_MSC_VER >= 1200))

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.

On 11/07/17 04:39, Gavin Lambert via Boost wrote:

On 7/11/2017 10:51, Andrey Semashev wrote:

...

You can see that gcc does not support autolinking from auto_link.hpp:

I think it's an ecosystem issue.

One of the main reasons why MSVC can support autolinking is that by default the linker does not care what order libraries are linked in -- anything in loose objects always wins over libraries, and it will search all the libraries for remaining unresolved symbols and error out if it finds symbols duplicated in multiple libraries.  Consequently Windows libraries generally rely on callback APIs and the like, not weak symbols.  (Although there are ways to use weak symbols, they're less popular.)

Meanwhile ELF binaries and linkers have traditionally had a specified linking order, where a symbol will only resolve to a library listed after it.  This doesn't lend itself well to auto-linking, since it's harder to control the order.  They also make no distinction between individual .o files and a .a file containing .o files.

(GCC does have a mode where it can link libraries in any order, similar to MSVC, but it's only recommended to resolve mutual dependencies and not for general use, since ELF libraries are more likely to rely on the existence of weak symbols to do link-time overrides, which in turn only works properly with ordered linking.)

It's just one of those things with the weight of tradition behind it, and isn't likely to be "fixed" any time soon.

Exactly, only I tend to think that the ecosystem was built around the different design of shared libraries on Windows rather than the other way around.