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

Subject: Re: [boost] [config] clang on Windows and BOOST_SYMBOL_EXPORT problem
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-02-14 21:17:59

On 2/14/2015 4:52 PM, Andrey Semashev wrote:
> 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.

After more comments on the clang developer's mailing list I have 
reported this bug to clang at http://llvm.org/bugs/show_bug.cgi?id=22591 
after being asked to do so on the developer's mailing list.