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

On 1/16/2015 11:29 AM, Peter Dimov wrote:

Beman Dawes wrote:

...

On Mon, Jan 5, 2015 at 12:07 PM, Peter Dimov 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:stdcxx0x : <cxxflags>-std=c++0x ; feature.compose toolset-clang:stdcxx11 : <cxxflags>-std=c++11 ; feature.compose toolset-clang:stdcxx1y : <cxxflags>-std=c++1y ; feature.compose toolset-clang:stdcxx14 : <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.