[filesystem] path.cpp fails to compile under clang/Cygwin
Fails like this: clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\filesystem\build\clang-linux-3.4.2\release\link-static\path.obj ..\..\..\libs\filesystem\src\path.cpp:36:11: fatal error: 'windows_file_codecvt.hpp' file not found # include "windows_file_codecvt.hpp" ^ 1 error generated. "clang++" -c -x c++ -Wno-variadic-macros -Wno-c99-extensions -O3 -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"..\..\..\include" -o "..\..\..\bin.v2\libs\filesystem\build\clang-linux-3.4.2\release\link-static\path.obj" "..\..\..\libs\filesystem\src\path.cpp" Looks like a clang bug; the file is certainly there, in the same directory as path.cpp.
I use wave to preprocess some user input, and a common input error is to have a space after the line continuation character, like #define SOME_MACRO \ value I poked around through documentation, but didn't see any configuration options for allowing a more relaxed line continuation of backslash + whitespace. Is there any simple way of doing this? I can work around it by doing a text substitution before passing the input to wave, but was hoping there was some way to enable it inside wave. ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message.
On Mon, Jan 5, 2015 at 11:31 AM, Peter Dimov <lists@pdimov.com> wrote:
Fails like this:
clang-linux.compile.c++.without-pth ..\..\..\bin.v2\libs\ filesystem\build\clang-linux-3.4.2\release\link-static\path.obj ..\..\..\libs\filesystem\src\path.cpp:36:11: fatal error: 'windows_file_codecvt.hpp' file not found # include "windows_file_codecvt.hpp" ^ 1 error generated.
"clang++" -c -x c++ -Wno-variadic-macros -Wno-c99-extensions -O3 -Wno-inline -Wall -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DNDEBUG -I"..\..\..\include" -o "..\..\..\bin.v2\libs\filesystem\build\clang-linux- 3.4.2\release\link-static\path.obj" "..\..\..\libs\filesystem\src\ path.cpp"
Looks like a clang bug; the file is certainly there, in the same directory as path.cpp.
Filesystem build and test with clang work for me. clang++ --version reports "Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5)" The regression tests for both master and develop also show quite a few linux clang results, and none are reporting any errors. So it looks like something is whacky that is specific to your setup. HTH, --Beman
On Mon, Jan 5, 2015 at 12:07 PM, Peter Dimov <lists@pdimov.com> 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? Thanks, --Beman
Beman Dawes wrote:
On Mon, Jan 5, 2015 at 12:07 PM, Peter Dimov <lists@pdimov.com> 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.)
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@pdimov.com> 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.)
I have never tried using clang with Cygwin but clang should now be working correctly with mingw, with the last fix I put in Boost Build for clang under Windows, and which has now been put in Boost Build 'master' as well as 'develop'. Of course I am speaking of clang for Windows built using mingw/gcc and not msvc. The msvc compatible implementation is highly problematical due to the clang developers replicating some of the VC++ preprocessor bugs, which breaks Boost PP which expects a standard conforming preprocessor for clang. Also the clang-win.jam which I added to Boost Build for the msvc compatible implementation of clang, and which is frankly based on someone else's implementation kindly available in another post, has never been integrated into Boost Build.
Edward Diener wrote:
I have never tried using clang with Cygwin...
To clarify, I'm not using clang _with_ Cygwin, that is, I am not using my own compiled clang with an existing Cygwin installation. I am using Cygwin's clang package, as installed by the Cygwin installer. Cygwin's g++ was for a long time stuck at 3.4.6, which made it not particularly viable for Boost testing, but it's on 4.8.3 now and I find it very useful, because it's a POSIX platform, which is good for test coverage. And it has -std=c++11. And clang. What's not to like? Only the fact that gcc.archive fails for some reason, which breaks all tests that want to statically link to Boost.Test. And that Boost.Test fails with -std=c++11 due to absence of mkstemp and putenv. But apart from that, it's perfect. :-)
On 1/16/2015 4:56 PM, Peter Dimov wrote:
Edward Diener wrote:
I have never tried using clang with Cygwin...
To clarify, I'm not using clang _with_ Cygwin, that is, I am not using my own compiled clang with an existing Cygwin installation. I am using Cygwin's clang package, as installed by the Cygwin installer.
Cygwin's g++ was for a long time stuck at 3.4.6, which made it not particularly viable for Boost testing, but it's on 4.8.3 now and I find it very useful, because it's a POSIX platform, which is good for test coverage. And it has -std=c++11. And clang. What's not to like? Only the fact that gcc.archive fails for some reason, which breaks all tests that want to statically link to Boost.Test. And that Boost.Test fails with -std=c++11 due to absence of mkstemp and putenv. But apart from that, it's perfect. :-)
I will try running the tests in Boost.Test with both gcc and clang under Windows, to see what the problems with clang are. Maybe I can figure out what is wrong with it.
On Fri, Jan 16, 2015 at 4:56 PM, Peter Dimov <lists@pdimov.com> wrote:
Edward Diener wrote:
I have never tried using clang with Cygwin...
To clarify, I'm not using clang _with_ Cygwin, that is, I am not using my own compiled clang with an existing Cygwin installation. I am using Cygwin's clang package, as installed by the Cygwin installer.
Cygwin's g++ was for a long time stuck at 3.4.6, which made it not particularly viable for Boost testing, but it's on 4.8.3 now
Better yet, 4.9.2 has been available for a few days now!
and I find it very useful, because it's a POSIX platform, which is good for test coverage.
+1. For stuff that I am worried about, I run Linux in a virtual machine, but for every day tests cygwin is great.
And it has -std=c++11. And clang. What's not to like? Only the fact that gcc.archive fails for some reason, which breaks all tests that want to statically link to Boost.Test.
I'm having failures for gcc on Windows with the three or four Filesystem test that link statically. It looks to me like Boost.Build is missing dependencies, so compiles aren't run soon enough and then the archive fails. So I'm wondering if the same problem is affecting Boost.Test. Boost.Timer is also failing gcc static links, but I haven't had a chance to look at that in any detail.
And that Boost.Test fails with -std=c++11 due to absence of mkstemp and putenv. But apart from that, it's perfect. :-)
I've run into the putenv problem, too. I fixed if for -std=c++11 but now I'm getting a failure for c++ 03 builds, so I've got to reinstate a fix for that case. --Beman
Beman Dawes wrote:
On Fri, Jan 16, 2015 at 4:56 PM, Peter Dimov <lists@pdimov.com> wrote:
And it has -std=c++11. And clang. What's not to like? Only the fact that gcc.archive fails for some reason, which breaks all tests that want to statically link to Boost.Test.
I'm having failures for gcc on Windows with the three or four Filesystem test that link statically. It looks to me like Boost.Build is missing dependencies, so compiles aren't run soon enough and then the archive fails. So I'm wondering if the same problem is affecting Boost.Test.
Not, it's not that. The problem appears to be that gcc.jam is using g++ -print-prog-name=ar to obtain the path to ar, and this returns /usr/lib/gcc/i686-pc-cygwin/4.8.3/../../../../i686-pc-cygwin/bin/ar.exe which would work in a Cygwin shell, but does not work in a cmd.exe shell, from where I invoke b2. At the moment, I have no idea how this can be fixed.
Beman Dawes wrote:
Better yet, 4.9.2 has been available for a few days now!
But, as I just discovered, it breaks Clang, because it can no longer find its stdlib headers (looks for 4.8.3). This might be why it doesn't work for you.
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@pdimov.com> 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.
participants (4)
-
Beman Dawes -
Edward Diener -
Nelson, Erik - 2 -
Peter Dimov