google
[BUG] Configuration failure with clang and cmake 3.24 on windows
Benchmark fails to configure when using clang++ (non cl) using CMake 3.24.
- OS: Windows 11
- Compiler and version: Clang 15 (gcc compatible driver)
- Earlier versions most likely fail too
- Cmake version 3.24.0
- ninja version: 1.11.0
To reproduce Steps to reproduce the behavior:
- sync to commit 974cd5a5c5a78e76ebc50961f4dbf3bf6d4ade4e (main at the time of writing)
- In a developer terminal try configuring with
cmake -GNinja -DCMAKE_CXX_COMPILER=clang++ -S . -B build - See error
(...)
-- Performing Test HAVE_STD_REGEX -- failed to compile: Change Dir: C:/Users/mesza/Desktop/Develpment/rocRAND/build/googlebenchmark-src/build/CMakeFiles/CMakeTmp
Run Build Command(s):C:/ProgramData/chocolatey/bin/ninja.exe cmTC_be128 && [1/2] Building CXX object CMakeFiles/cmTC_be128.dir/std_regex.cpp.obj
FAILED: CMakeFiles/cmTC_be128.dir/std_regex.cpp.obj
CLANG_~1.EXE -std=c++11 -Wall -Wextra -Wshadow -Wfloat-equal -pedantic -pedantic-errors -Wshorten-64-to-32 -fstrict-aliasing -Wno-deprecated-declarations -Wstrict-aliasing -Wthread-safety -g -Xclang -gcodeview -O0 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -MD -MT CMakeFiles/cmTC_be128.dir/std_regex.cpp.obj -MF CMakeFiles\cmTC_be128.dir\std_regex.cpp.obj.d -o CMakeFiles/cmTC_be128.dir/std_regex.cpp.obj -c C:/Users/mesza/Desktop/Develpment/rocRAND/build/googlebenchmark-src/cmake/std_regex.cpp
In file included from C:/Users/mesza/Desktop/Develpment/rocRAND/build/googlebenchmark-src/cmake/std_regex.cpp:1:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.32.31326\include\regex:12:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.32.31326\include\algorithm:11:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.32.31326\include\xmemory:13:
In file included from C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.32.31326\include\limits:16:
C:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.32.31326\include\xstddef:260:22: error: 'auto' return without trailing return type; deduced return types are a C++14 extension
_NODISCARD constexpr auto _Unfancy(_Ptrty _Ptr) noexcept { // converts from a fancy pointer to a plain pointer
(...)
CMake Error at CMakeLists.txt:308 (message):
Failed to determine the source files for the regular expression backend
Expected behavior Configuring should work without problems.
Additional context https://github.com/google/benchmark/pull/1021 solved the same problem (https://github.com/google/benchmark/issues/974) for clang 10.
I believe it does not work here, because cmake does not add the c++14 flag to clang 15 as it's default, therefore the inherited flag (from CMakeLists.txt:174) takes precedent.
If CMAKE_CXX_STANDARD in CMakeLists.txt:299 is changed to 17 then the error goes away. In this case cmake adds the -std=gnu++17 compile flag.
The compilation command then looks like this: (Note the two -std options, one from the CXXFLAGS of googlebenchmark, and the other added by CMake because due to CMAKE_CXX_STANDARD.
"CLANG_~1.EXE -std=c++11 -Wall -Wextra -Wshadow -Wfloat-equal -pedantic -pedantic-errors -Wshorten-64-to-32 - fstrict-aliasing -Wno-deprecated-declarations -Wstrict-aliasing -Wthread-safety -g -Xclang -gcodeview -O0 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -std=gnu++17"
Attachments: Full cmake log
i think we need some windows+clang CI bots to catch this sort of thing.
can we just update it to 17 or do we need to set it based on the version of clang?
i think we need some windows+clang CI bots to catch this sort of thing.
Sounds like a good idea, according to github Windows 2019 readme and github windows 2022 readme the github windows runners have the Microsoft.VisualStudio.Component.VC.Llvm.Clang visual studio component installed so clang should be available (at least clang-cl, not sure about clang++ the gcc compatible driver)
can we just update it to 17 or do we need to set it based on the version of clang?
I wrote that "fix" as more of an explanation instead of a suggestion. I would consider that as very short term hack only, in the future clang could default to c++17 and cmake could drop the flag again.
Is there a reason why the c++ standard is set like this (into CMAKE_CXX_FLAGS directly) instead of setting CMAKE_CXX_STANDARD to 11?
Even better would be to move all the flags to a utility target, setting them via target_compile_options, then linking everything to this target. This way even the warning flags wouldn't get propagated to try_compile/try_run.
i think we need some windows+clang CI bots to catch this sort of thing.
Sounds like a good idea, according to github Windows 2019 readme and github windows 2022 readme the github windows runners have the
Microsoft.VisualStudio.Component.VC.Llvm.Clangvisual studio component installed so clang should be available (at leastclang-cl, not sure aboutclang++the gcc compatible driver)
https://github.com/actions/runner-images/issues/2257 suggests a solution. i'll add it to my backlog.
can we just update it to 17 or do we need to set it based on the version of clang?
I wrote that "fix" as more of an explanation instead of a suggestion. I would consider that as very short term hack only, in the future clang could default to c++17 and cmake could drop the flag again.
Is there a reason why the c++ standard is set like this (into
CMAKE_CXX_FLAGSdirectly) instead of settingCMAKE_CXX_STANDARDto 11?
no reason, no. if it's the wrong thing to do then we should fix that.
Even better would be to move all the flags to a utility target, setting them via
target_compile_options, then linking everything to this target. This way even the warning flags wouldn't get propagated totry_compile/try_run.
sgtm.
we should be setting the standard correctly now so i'm closing (i have no way to test). reopen if it's still an issue please.