Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at