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 17:53:51

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.

You are correct. It was my error in my explanation here of the 
situation. I did correctly point out to the clang developers that 
compiling with gcc/mingw using __attribute__((__dllexport__)) does 
compile the example I gave without errors, that compiling with VC++ 
using __declspec(dllexport) does compile the example I gave without 
errors, but that clang fails to do so using either.

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

Thanks for the explanation. So we really have no way to solve this from 
within Boost.

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

Actually clang only aims for compatibility with MSVC in their clang for 
Windows version which targets VC++. In their clang for Windows 
implementation which targets mingw/gcc they do aim for a certain amount 
of compatibility with mingw/gcc. I am using the version of clang on 
Windows targeting mingw/gcc. The version on Windows which targets VC++, 
which I have been able to build, I never use because 1) it replicates 
some of the VC++ preprocessor bugs breaking Boost PP and 2) It is not 
supported directly in Boost Build ( although I can workaround that 
problem ).

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

I agree with that but so far nobody at clang has continued the 
discussion after an initial flurry of responses.

Thanks for the clarification and I apologize for the confusion reporting 
the issue here.