Re: [boost] [config] clang on Windows and BOOST_SYMBOL_EXPORT problem

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 
visibility.

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.