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