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-15 10:52:58

On 2/15/2015 3:22 AM, Andrey Semashev wrote:
> On Saturday 14 February 2015 17:53:51 Edward Diener wrote:
>> On 2/14/2015 4:52 PM, Andrey Semashev wrote:
>>
>>> 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.
>
> Hmm, I didn't know there were two clangs for Windows. Confusing... Anyway,
> since gcc compiles this code the same argument applies.

The clang developers decided they wanted a version of clang which could 
replace VC++ in Visual Studio. Unfortunately to do so they have sought 
to replicate all VC++ bugs, including those of VC++'s broken 
preprocessor. I have worked with Paul on Boost PP and neither I nor he ( 
presumably ) are willing to find a further set of workarounds for yet a 
different set of VC++-like preprocessor bugs to accomodate clang for 
Windows targeting VC++. So I don't bother with trying to use that 
version of clang on Windows ( often called clang_cl ).

The other clang for Windows targets mingw(64)/gcc and while it is very 
close to the Linux version of clang there are a few subtle differences 
due to the fact that it run under Windows and produces Windows dlls and 
exes. That's a version I can test with and which is supported in Boost 
and by Boost Build, and it's the version which shows the clang 'export' 
bug on Windows which I have brought up with the clang developers. The 
bug manifests itself using Boost with Boost.Test which exports the 
ExecutionMonitor class, which is non-copyable and non-assignable.

In the past I had tried to convince the clang developers that the broken 
VC++ preprocessor that they are trying to replicate in the clang Windows 
version targeting VC++ should only manifest its brokenness when dealing 
with VC++ header files ( where evidently such brokenness is needed ), 
but should work like clang's normal C++ standard preprocessor otherwise. 
But they did not want to implement that AFAICS. In which case I do not 
believe that using that version with most Boost libraries is ever going 
to work. However using the clang version that targets mingw(64)/gcc on 
Windows should give one a very good C++ standard conforming compiler to 
test Boost with on Windows.

This should give some explanation of the two different versions of clang 
on Windows. They can be distinguished in code by the fact that the clang 
version targeting VC++ defines the _MSC_VER macro and the version 
targeting mingw(64)/gcc does not define the _MSC_VER macro.

Thanks for your concern here regarding Boost. I probably should not have 
brought up the issue of the bug here but I was thinking ( erroneously ) 
of finding a simple workaround in config for it until it gets officially 
fixed by clang.