Re: [boost] [filesystem] path.cpp fails to compile underclang/Cygwin

Subject: Re: [boost] [filesystem] path.cpp fails to compile underclang/Cygwin
From: Edward Diener (eldiener_at_[hidden])
Date: 2015-01-17 16:25:09

On 1/16/2015 11:29 AM, Peter Dimov wrote:
> Beman Dawes wrote:
>
>> On Mon, Jan 5, 2015 at 12:07 PM, Peter Dimov <lists_at_[hidden]> wrote:
>> >
>> > My clang is the Cygwin one, running under Windows.
>>
>> I'm having no luck at all with "b2 toolset=clang" on Windows.
>>
>> What does your "using" entry in user-config.jam look like?
>
> using clang : : : <cxxflags>-Wno-variadic-macros
> <cxxflags>-Wno-c99-extensions ;
>
> feature.subfeature toolset clang : std : cxx0x cxx11 cxx1y cxx14 :
> optional composite propagated ;
>
> feature.compose <toolset-clang:std>cxx0x : <cxxflags>-std=c++0x ;
> feature.compose <toolset-clang:std>cxx11 : <cxxflags>-std=c++11 ;
> feature.compose <toolset-clang:std>cxx1y : <cxxflags>-std=c++1y ;
> feature.compose <toolset-clang:std>cxx14 : <cxxflags>-std=c++14 ;
>
> but I doubt that this is the issue. I'm also on the develop branch, if
> that makes a difference.
>
> I had many problems with clang when I tried to make it work on mingw,
> but the Cygwin version (installed via the Cygwin installer) works out of
> the box (well, apart from the relative include bug.)

Running Boost.Test using clang targeting mingw/gcc I am running into a 
problem with "exported" classes, which are 
'__attribute__((__visibility__("default")))' in clang. Evidently when 
clang 'exports' a class it attempts to generate a default copy 
constructor and a default assignment operator when no user-defined 
functionality is specified, even when no copying or assigning is done 
for any instance of that class. This causes it to produce errors for a 
number of Boost.Test classes, execution_monitor in particular, using a 
member of the non-copyable, non-assignable boost:scoped_ptr type.

Has anyone run into this with Boost.Test or any other Boost library 
compiled with clang ? Is this a known issue with clang ?

I reported this on the clang developer's list, although the 'export' 
reason for the bug was spotted by a clang developer and not me.

I am curious that this does not show up for you with cygwin, but maybe 
this is the cause of some of Beman's problems with clang. This is 
compiling clang in non-c++11 mode.