Boost logo

Boost :

Subject: Re: [boost] [config] clang on Windows and BOOST_SYMBOL_EXPORT problem
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2015-02-14 16:52:59

On Saturday 14 February 2015 14:38:35 Edward Diener wrote:
> Do we want to change BOOST_SYMBOL_EXPORT on clang with Windows targeting
> mingw/gcc to specify __attribute__((__visibility__("default"))) as we do
> with mingw/gcc ?

First, on Windows for gcc/mingw __attribute__((__dllexport__)) is used, not

The way I understand it, __declspec(dllexport) (or the similar attribute) is
not equivalent to __attribute__((__visibility__("default"))), even if the
latter does have a sensible meaning on Windows. Exported symbols are mangled
differently, and on the import side shims are generated for the imported
functions (not sure if there are other consequences for classes and data, but
there probably are, at least to support delayed library loading). Visibility
attribute does not affect mangling nor generates anything but simply marks the
symbol for the linker to be externally visible or not. This makes no sense on
Windows since its linker only works with exported symbols. Note that by
default all symbols are visible but certainly not exported.

I suspect, if you make BOOST_SYMBOL_EXPORT to be
__attribute__((__visibility__("default"))), you won't be able to link with
those symbols from other libraries/applications compiled with clang or other
compilers. And there is also GetProcAddress() to consider.

My position on this issue is that as long as clang team aims for compatibility
with MSVC, they should make clang work similarly to MSVC. If MSVC compiles
that code, then it probably doesn't generate (nor export) these functions if
they can't be generated. Such behavior would seem sensible to me because
otherwise there would be no way to export non-copyable classes. IMHO, clang
should follow.

Boost list run by bdawes at, gregod at, cpdaniel at, john at