CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2018-02-20T16:28:55-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/16266Ninja generator passes -std option to clang-cl2018-02-20T16:28:55-05:00Jørgen IbsenNinja generator passes -std option to clang-clWhen Ninja is targeting Clang's MSVC compatible tools (clang-cl), and you require a certain C++ version, it passes the `-std` option, which Clang 3.8.1 does not accept.
For this example:
~~~.cmake
cmake_minimum_required(VERSION 3.6)...When Ninja is targeting Clang's MSVC compatible tools (clang-cl), and you require a certain C++ version, it passes the `-std` option, which Clang 3.8.1 does not accept.
For this example:
~~~.cmake
cmake_minimum_required(VERSION 3.6)
project(foo CXX)
add_executable(foo foo.cpp)
set_property(TARGET foo PROPERTY CXX_STANDARD "11")
set_property(TARGET foo PROPERTY CXX_STANDARD_REQUIRED TRUE)
~~~
~~~.cpp
int main() { auto i = 5; }
~~~
I get:
~~~
[1/2] Building CXX object CMakeFiles\foo.dir\foo.cpp.obj
FAILED: CMakeFiles/foo.dir/foo.cpp.obj
D:\LLVM\msbuild-bin\cl.exe /nologo /D_DEBUG /MDd /Zi /Ob0 /Od /RTC1 -std=gnu++11 /showIncludes /FoCMakeFiles\foo.dir\foo.cpp.obj /FdCMakeFiles\foo.dir\ -c foo.cpp
clang-cl.exe: error: unknown argument: '-std=gnu++11'
ninja: build stopped: subcommand failed.
~~~
3.10.0https://gitlab.kitware.com/cmake/cmake/-/issues/17518ToT Clang on Windows does not work2019-02-18T07:55:06-05:00Loo Rong JieToT Clang on Windows does not workIn October, CMake added a check to test if `--version` flag is available in clang [1]. If the flag is available, it should mean it is `clang.exe` or `clang++.exe` instead of `clang-cl.exe`.
However, `--version` was added into `clang-cl....In October, CMake added a check to test if `--version` flag is available in clang [1]. If the flag is available, it should mean it is `clang.exe` or `clang++.exe` instead of `clang-cl.exe`.
However, `--version` was added into `clang-cl.exe` as well in the same month [2]!
Please revert [1].
- [1]: https://gitlab.kitware.com/cmake/cmake/commit/b6d3a1c09a796ec0c29074c387953fb88ebfe874
- [2]: https://github.com/llvm-mirror/clang/commit/c5924addeeea29249ddbf048d3860c9e2198d2893.10.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/18396Apple Clang for Xcode 10.0 not supported with MACOSX_DEPLOYMENT_TARGET=10.72019-02-07T06:45:45-05:00slodkiApple Clang for Xcode 10.0 not supported with MACOSX_DEPLOYMENT_TARGET=10.7CMake generates an error on first `PROJECT()` with C++:
```
-- The C compiler identification is AppleClang 10.0.0.10001145
-- The CXX compiler identification is AppleClang 10.0.0.10001145
-- Check for working C compiler: /Applications/X...CMake generates an error on first `PROJECT()` with C++:
```
-- The C compiler identification is AppleClang 10.0.0.10001145
-- The CXX compiler identification is AppleClang 10.0.0.10001145
-- Check for working C compiler: /Applications/Xcode-10.0.app/Contents/Developer/usr/bin/gcc
-- Check for working C compiler: /Applications/Xcode-10.0.app/Contents/Developer/usr/bin/gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode-10.0.app/Contents/Developer/usr/bin/g++
-- Check for working CXX compiler: /Applications/Xcode-10.0.app/Contents/Developer/usr/bin/g++ -- broken
CMake Error at /usr/local/Cellar/cmake/3.12.2/share/cmake/Modules/CMakeTestCXXCompiler.cmake:45 (message):
The C++ compiler
"/Applications/Xcode-10.0.app/Contents/Developer/usr/bin/g++"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/travis/build/slodki/moneymanagerex/build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/make" "cmTC_4e61e/fast"
/Applications/Xcode-10.0.app/Contents/Developer/usr/bin/make -f CMakeFiles/cmTC_4e61e.dir/build.make CMakeFiles/cmTC_4e61e.dir/build
Building CXX object CMakeFiles/cmTC_4e61e.dir/testCXXCompiler.cxx.o
/Applications/Xcode-10.0.app/Contents/Developer/usr/bin/g++ -isysroot /Applications/Xcode-10.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.7 -o CMakeFiles/cmTC_4e61e.dir/testCXXCompiler.cxx.o -c /Users/travis/build/slodki/moneymanagerex/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
warning: include path for stdlibc++ headers not found; pass '-std=libc++' on the command line to use the libc++ standard library instead [-Wstdlibcxx-not-found]
1 warning generated.
Linking CXX executable cmTC_4e61e
/usr/local/Cellar/cmake/3.12.2/bin/cmake -E cmake_link_script CMakeFiles/cmTC_4e61e.dir/link.txt --verbose=1
/Applications/Xcode-10.0.app/Contents/Developer/usr/bin/g++ -isysroot /Applications/Xcode-10.0.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk -mmacosx-version-min=10.7 -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/cmTC_4e61e.dir/testCXXCompiler.cxx.o -o cmTC_4e61e
clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
ld: library not found for -lstdc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [cmTC_4e61e] Error 1
make: *** [cmTC_4e61e/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:36 (PROJECT)
-- Configuring incomplete, errors occurred!
```
Is there any workaround to force stdlib param to compiler/linker before first `PROJECT()` call?
Both combinations:
* Xcode 9.x and MACOSX_DEPLOYMENT_TARGET=10.7
* Xcode 10.0 and MACOSX_DEPLOYMENT_TARGET=10.9
works and only
* Xcode 10.0 and MACOSX_DEPLOYMENT_TARGET=10.7
is not working3.14.0Gregor JasnyGregor Jasnyhttps://gitlab.kitware.com/cmake/cmake/-/issues/17804vs_link_exe / vs_link_dll ignores CMAKE_RC_COMPILER2019-02-18T07:52:55-05:00Mark Ingramvs_link_exe / vs_link_dll ignores CMAKE_RC_COMPILERvs_link_exe / vs_link_dll require `rc.exe` to be in your path in order to succeed. I realise these are internal functions, but they're called as part of the initial compiler identification. If I configure CMake with:
```
CMAKE_CXX_COMPI...vs_link_exe / vs_link_dll require `rc.exe` to be in your path in order to succeed. I realise these are internal functions, but they're called as part of the initial compiler identification. If I configure CMake with:
```
CMAKE_CXX_COMPILER="C:/Program Files/LLVM/bin/clang-cl.exe"
CMAKE_LINKER="C:/Program Files/LLVM/bin/lld-link.exe"
CMAKE_RC_COMPILER="C:/Program Files (x86)/Windows Kits/10/bin/x64/rc.exe"
```
Then I would expect `CMAKE_RC_COMPILER` to be used in-place of a hardcoded `rcCommand.push_back("rc");` (cmcmd.cxx, line 1794).
It's worth noting that `CMAKE_LINKER` must be an absolute path, else linking will fail as well.3.14.0https://gitlab.kitware.com/cmake/cmake/-/issues/19496Clang GNU: MSVC standard library usage requirements2020-02-02T07:20:42-05:00Daan De MeyerClang GNU: MSVC standard library usage requirementsWith the new Windows Clang GNU frontend variant support, a lot of projects are failing to compile because they specify C++11 as the CMake standard but depend on the MSVC standard library headers which use C++14. I've been fixing these pr...With the new Windows Clang GNU frontend variant support, a lot of projects are failing to compile because they specify C++11 as the CMake standard but depend on the MSVC standard library headers which use C++14. I've been fixing these projects by checking if the Clang GNU frontend is used on Windows and increasing the C++ version if this is the case but ideally, CMake would automatically add the correct usage requirements to each target depending on which standard library is used.
So for example, a project that uses the MSVC stdlib would have C++14 usage requirements added to all its C++ targets by CMake.3.15.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20021Clang/LLVM-MinGW: Implicit include directories detected with newlines2019-12-16T10:40:23-05:00Cristian AdamClang/LLVM-MinGW: Implicit include directories detected with newlinesThe [Clang/LLVM-MinGW](https://github.com/mstorsjo/llvm-mingw) toolchain is producing the following `CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES` entry in `CMakeCXXCompiler.cmake`:
```cmake
set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES "C:/llvm...The [Clang/LLVM-MinGW](https://github.com/mstorsjo/llvm-mingw) toolchain is producing the following `CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES` entry in `CMakeCXXCompiler.cmake`:
```cmake
set(CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES "C:/llvm-mingw/include/c++/v1
;C:/llvm-mingw/lib/clang/9.0.0/include
;C:/llvm-mingw/include
")
```
Which causes problems in identifying if an include path is part of the implicit include directories list.3.15.6Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20529llvm-rc: Compiling RC files no longer finds adjacent data files2020-04-07T08:00:50-04:00delthasllvm-rc: Compiling RC files no longer finds adjacent data filesWhen compiling Windows RC files on the Windows-Clang platform, with llvm-rc, the folder of the resource is not added to the resource compiler include path.
This is a fairly serious bug for projects using Windows RC files that are compil...When compiling Windows RC files on the Windows-Clang platform, with llvm-rc, the folder of the resource is not added to the resource compiler include path.
This is a fairly serious bug for projects using Windows RC files that are compiled with the Windows-Clang platform and in particular `llvm-rc`, caused by !4219.
When compiling a Windows resource file with `llvm-rc`, CMake used to simply invoke `llvm-rc` on that resource file in its original source folder.
Since that patch, CMake instead invokes its own command-line tool `cmake_llvm_rc` that does two steps:
- preprocess that resource file into an intermediary preprocessed resource file, somewhere in the CMakeFiles build folder
- invoke `llvm-rc` on that new file.
The cause of the bug is that `llvm-rc` now processes the resource file in the new folder, rather than in its original source folder.
Now consider a project where a resource file `resource.rc` references a resource `resource.dat` in its current directory, like so (this is not an edge-case, it is a typically way to reference and include a resource file into an executable):
```4 RCDATA "resource.dat"```
To look up the reference file in order to read it, `llvm-rc` [mimicks the original behaviour of the Windows Resource Compiler and looks up paths in the following order](https://github.com/llvm-mirror/llvm/blob/master/tools/llvm-rc/ResourceFileWriter.cpp#L1511):
- if the file path is absolute and exists, try to use that; otherwise:
- search in the current working directory
- **search in the directory of the input resource file**
- search in all of the include directories specified on the command line
The path used to be matched by the third case *(search in the directory of the input resource file)*, because that direcotry was indeed the directory that contained the resource file and in our example the resource as well.
But now, the directory of the input resource file has changed and is now inside the CMakeFiles folder which does not contain the resource. So none of the paths contain that resource and the file cannot be looked up, **resulting in a build failure**.
To me the simplest way to fix this would be to add to the include directories specified on the command line of `llvm-rc`, the path of the folder containing the original resource file. Specifically perhaps modify [that line in Platform/Windows-Clang.cmake](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/Platform/Windows-Clang.cmake#L145) to add a `/I <SOURCE_DIR>` where `SOURCE_DIR` is the folder containing `SOURCE`.3.17.1https://gitlab.kitware.com/cmake/cmake/-/issues/20504CMake 3.17: ClangCL: No CMAKE_CXX_COMPILER could be found2020-04-07T06:59:39-04:00Petr DannhoferCMake 3.17: ClangCL: No CMAKE_CXX_COMPILER could be foundUsing CMake 3.17.0, generator fails with given output below. CMakeOutput.log gives 0 warnings and errors. CMake 3.16.5 works fine.
```
Env params:
set _GEN=Visual Studio 16 2019
set _ARCH=x64
set _TOOLSET=ClangCL
CMD: project("MI17_RO...Using CMake 3.17.0, generator fails with given output below. CMakeOutput.log gives 0 warnings and errors. CMake 3.16.5 works fine.
```
Env params:
set _GEN=Visual Studio 16 2019
set _ARCH=x64
set _TOOLSET=ClangCL
CMD: project("MI17_ROM" CXX)
/////////////////////////////////////////////////////////////////////////////////////////
-- The CXX compiler identification is Clang 10.0.0 with MSVC-like command-line
CMake Error at CMakeLists.txt:9 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
See also "I:/dev/_bin/msvs16_x64_ClangCL/MI17_ROM/CMakeFiles/CMakeOutput.log".
CMAKEBUILD_ERROR: Configuration/generation failed.
/////////////////////////////////////////////////////////////////////////////////////////
```3.17.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/20754CUDA: Forward toolkit path to Clang2020-06-15T09:25:35-04:00Raul Tambreraul@tambre.eeCUDA: Forward toolkit path to ClangCMake should forward the path to the CUDA toolkit user wants to use to Clang as `--cuda-path` instead of relying on Clang to find the system CUDA installation, which might not be the one the user wants to use.
Reported initially in #20751.CMake should forward the path to the CUDA toolkit user wants to use to Clang as `--cuda-path` instead of relying on Clang to find the system CUDA installation, which might not be the one the user wants to use.
Reported initially in #20751.3.18.0Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/20726CUDA: Support CUDA_SEPARABLE_COMPILATION on Clang2020-09-25T12:25:35-04:00Raul Tambreraul@tambre.eeCUDA: Support CUDA_SEPARABLE_COMPILATION on Clang- [ ] Refactor relocatable device code flag, so we can use `-fgpu-rdc` instead of the NVCC-specific `-dc`.
- [ ] Device linking. [Bazel implementation](https://github.com/tensorflow/tensorflow/blob/ed371aa5d266222c799a7192e438cdd8c00464f...- [ ] Refactor relocatable device code flag, so we can use `-fgpu-rdc` instead of the NVCC-specific `-dc`.
- [ ] Device linking. [Bazel implementation](https://github.com/tensorflow/tensorflow/blob/ed371aa5d266222c799a7192e438cdd8c00464fe/third_party/nccl/build_defs.bzl.tpl).3.19.0Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/21789clang++: error: unknown argument: '-imsvc' when cross compiling on Windows2021-02-10T07:46:38-05:00Rianclang++: error: unknown argument: '-imsvc' when cross compiling on WindowsWe use ExternalProject_Add and a custom toolchain file (below), to cross compile with Clang/LLVM. On Linux, this works great, with no issues. On Windows, we get:
```
clang++: error: unknown argument: '-imsvc'
```
I tracked this down to:...We use ExternalProject_Add and a custom toolchain file (below), to cross compile with Clang/LLVM. On Linux, this works great, with no issues. On Windows, we get:
```
clang++: error: unknown argument: '-imsvc'
```
I tracked this down to:
```
if("x${CMAKE_C_SIMULATE_ID}" STREQUAL "xMSVC"
OR "x${CMAKE_CXX_SIMULATE_ID}" STREQUAL "xMSVC"
OR "x${CMAKE_Fortran_SIMULATE_ID}" STREQUAL "xMSVC")
macro(__compiler_clang lang)
set(CMAKE_INCLUDE_SYSTEM_FLAG_${lang} "-imsvc ")
endmacro()
else()
```
If I comment this out, it works great. Everything compiles and links without an issue. My concern is, I am not sure if that is the right approach or not. If I look at the output to the compiler, I see:
```
C:\working\llvm-project-build\Debug\bin\clang++.exe --target=x86_64-elf -ffreestanding -mno-mmx -mno-sse -mno-sse2 -mno-sse3 -mno-ssse3 -mno-sse4.1 -mno-sse4.2 -mno-sse4 -mno-avx -mno-aes -mno-sse4a -mcmodel=large -DBSL_DEBUG_LEVEL=bsl::V -DBSL_PAGE_SIZE=0x1000 -DENABLE_COLOR=true -IC:/working/hypervisor/runtime/../syscall/include/cpp -IC:/working/hypervisor/runtime/include -IC:/working/bsl/cmake/interface/../../include -IC:/working/bsl/cmake/interface/../../include/bsl/arch/x86 -imsvc include -Og -g -Wframe-larger-than=1024 -ftime-trace -Weverything -Wno-c++98-compat -Wno-c++98-compat-pedantic -Wno-c++20-compat -Wno-c11-extensions -Wno-padded
-Wno-weak-vtables -Wno-ctad-maybe-unsupported -Wno-enum-compare-conditional -Wno-return-std-move-in-c++11 -Wno-missing-prototypes -Wno-missing-variable-declarations -Wno-covered-switch-default -fcomment-block-commands=include -fcomment-block-commands=cond -fcomment-block-commands=endcond -fdiagnostics-color=always -fansi-escape-codes -fno-exceptions -fno-rtti -fstack-protector-strong -std=c++20 -o runtime/CMakeFiles/runtime.dir/src/_start.cpp.obj -c C:/working/hypervisor/runtime/src/_start.cpp
```
Everything here looks good minus the "-imsvc include".
Any thoughts on how to properly address this? Is there a variable I can set in the toolchain to fix this? Not really sure where to go from here. One option is I could write a custom wrapper around the compiler to filter this out, but that would be pretty annoying.
Thanks a ton
------------
```
#
# Copyright (C) 2020 Assured Information Security, Inc.
#
# Permission is hereby granted, free of charge, to any person obtaining a copy
# of this software and associated documentation files (the "Software"), to deal
# in the Software without restriction, including without limitation the rights
# to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
# copies of the Software, and to permit persons to whom the Software is
# furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in all
# copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
# OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
# SOFTWARE.
set(CMAKE_SYSTEM_NAME Generic)
set(CMAKE_CXX_COMPILER_WORKS 1)
string(CONCAT HYPERVISOR_EXT_CXX_FLAGS
"--target=x86_64-elf "
"-ffreestanding "
"-mno-mmx "
"-mno-sse "
"-mno-sse2 "
"-mno-sse3 "
"-mno-ssse3 "
"-mno-sse4.1 "
"-mno-sse4.2 "
"-mno-sse4 "
"-mno-avx "
"-mno-aes "
"-mno-sse4a "
"-mcmodel=large "
)
string(CONCAT HYPERVISOR_EXT_LINK_FLAGS
"-static "
"-nostdlib "
"-z noexecstack "
"-T ${CMAKE_BINARY_DIR}/toolchain/x64/ext.ld "
)
set(CMAKE_ASM_COMPILE_OBJECT
"<CMAKE_CXX_COMPILER> ${HYPERVISOR_EXT_CXX_FLAGS} <DEFINES> <INCLUDES> <FLAGS> -o <OBJECT> -c <SOURCE>")
set(CMAKE_CXX_COMPILE_OBJECT
"<CMAKE_CXX_COMPILER> ${HYPERVISOR_EXT_CXX_FLAGS} <DEFINES> <INCLUDES> <FLAGS> -o <OBJECT> -c <SOURCE>")
set(CMAKE_CXX_LINK_EXECUTABLE
"${HYPERVISOR_CXX_LINKER} ${HYPERVISOR_EXT_LINK_FLAGS} <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>"
)
```
And for reference, all of the code is here:
https://github.com/Bareflank/hypervisor3.19.5Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21613Windows clang not honoring WIN32_EXECUTABLE flag2021-01-04T13:49:28-05:00Michael Ziminsky (Z)Windows clang not honoring WIN32_EXECUTABLE flagUsing `clang`, not `clang-cl`, on Windows doesn't set `CMAKE_CREATE_WIN32_EXE`. This results in no explicit subsystem being set during linking and causes `lld-link` to choose automatically. `lld-link` makes its choice based on the presen...Using `clang`, not `clang-cl`, on Windows doesn't set `CMAKE_CREATE_WIN32_EXE`. This results in no explicit subsystem being set during linking and causes `lld-link` to choose automatically. `lld-link` makes its choice based on the presence of either a `main` or `WinMain` function, which is fine most of the time, but defaults to `/subsystem:console` when both are present such as when linking to `qtmain.lib`.
I fixed this locally by copying the definitions from `Windows-MSVC.cmake` to `Windows-Clang.cmake` and prefixing them with `-Xlinker`, but I'm not sure if that is the desired solution or not.
```cmake
if(CMAKE_SYSTEM_NAME STREQUAL "WindowsCE")
set(CMAKE_CREATE_WIN32_EXE "-Xlinker /entry:WinMainCRTStartup")
set(CMAKE_CREATE_CONSOLE_EXE "-Xlinker /entry:mainACRTStartup")
set(_PLATFORM_LINK_FLAGS " -Xlinker /subsystem:windowsce")
else()
set(CMAKE_CREATE_WIN32_EXE "-Xlinker /subsystem:windows")
set(CMAKE_CREATE_CONSOLE_EXE "-Xlinker /subsystem:console")
set(_PLATFORM_LINK_FLAGS "")
endif()
```3.20.0Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/21863clang-cuda compiler checks fail due to broken linker paths2021-02-25T09:03:12-05:00Tobias Ribizelclang-cuda compiler checks fail due to broken linker pathsThe following minimal test case fails on the master branch:
```
CMakeLists.txt:
cmake_minimum_required(VERSION 3.19)
project(Test CUDA)
CMake invocation:
../CMake/build/bin/cmake -DCMAKE_CUDA_COMPILER=clang++ ..
```
Error output:
```
...The following minimal test case fails on the master branch:
```
CMakeLists.txt:
cmake_minimum_required(VERSION 3.19)
project(Test CUDA)
CMake invocation:
../CMake/build/bin/cmake -DCMAKE_CUDA_COMPILER=clang++ ..
```
Error output:
```
-- Check for working CUDA compiler: /usr/bin/clang++ - broken
CMake Error at CMake/Modules/CMakeTestCUDACompiler.cmake:52 (message):
The CUDA compiler
"/usr/bin/clang++"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /build/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make -f Makefile cmTC_01c87/fast && /usr/bin/make -f CMakeFiles/cmTC_01c87.dir/build.make CMakeFiles/cmTC_01c87.dir/build
make[1]: Entering directory '/build/CMakeFiles/CMakeTmp'
Building CUDA object CMakeFiles/cmTC_01c87.dir/main.cu.o
/usr/bin/clang++ --cuda-gpu-arch=sm_30 --cuda-path=/usr/local/cuda -MD -MT CMakeFiles/cmTC_01c87.dir/main.cu.o -MF CMakeFiles/cmTC_01c87.dir/main.cu.o.d -x cuda -c /build/CMakeFiles/CMakeTmp/main.cu -o CMakeFiles/cmTC_01c87.dir/main.cu.o
Linking CUDA executable cmTC_01c87
/CMake/build/bin/cmake -E cmake_link_script CMakeFiles/cmTC_01c87.dir/link.txt --verbose=1
/usr/bin/clang++ CMakeFiles/cmTC_01c87.dir/main.cu.o -o cmTC_01c87 -lcudadevrt -lcudart_static -lrt -lpthread -ldl
/usr/bin/ld: cannot find -lcudadevrt
/usr/bin/ld: cannot find -lcudart_static
clang: error: linker command failed with exit code 1 (use -v to see invocation)
CMakeFiles/cmTC_01c87.dir/build.make:99: recipe for target 'cmTC_01c87' failed
make[1]: *** [cmTC_01c87] Error 1
make[1]: Leaving directory '/build/CMakeFiles/CMakeTmp'
Makefile:127: recipe for target 'cmTC_01c87/fast' failed
make: *** [cmTC_01c87/fast] Error 2
```
My environment:
```
Ubuntu clang version 10.0.1-++20201112101950+ef32c611aa2-1~exp1~20201112092551.202
Cuda compilation tools, release 10.1, V10.1.243
```
I bisected the issue down to 4620cf77f27a63163e0c101dbe28632039a3588a, though with previous versions, the compiler check just gets skipped.3.21.0Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/22487LINK_WHAT_YOU_USE adds -Wl,--no-as-needed to static libraries2021-08-07T08:08:07-04:00ajpennerLINK_WHAT_YOU_USE adds -Wl,--no-as-needed to static librariesWhen I enable the LINK_WHAT_YOU_USE option with cmake version 3.21.* I am finding that this now adds the "-Wl,--no-as-needed" linker option to the archiver used for static libraries. This option is not valid for the archiver and as a res...When I enable the LINK_WHAT_YOU_USE option with cmake version 3.21.* I am finding that this now adds the "-Wl,--no-as-needed" linker option to the archiver used for static libraries. This option is not valid for the archiver and as a result the build fails. If I rollback my cmake version to 3.18.5 everything works as expected. I am operating on production code so I did not pin down the exact version that exposes this bug.3.21.2https://gitlab.kitware.com/cmake/cmake/-/issues/22482CUDA/Clang: "No rule to make target" with clang++-122021-07-29T08:45:47-04:00Serge RogatchCUDA/Clang: "No rule to make target" with clang++-12After setting `clang++-12` as the CUDA compiler, the build after CMake configuration produces an error like:
`make[2]: *** No rule to make target 'CMakeFiles/cudalink_exe.dir/exe2.cpp.o', needed by 'CMakeFiles/cudalink_exe.dir/sm_75.cubi...After setting `clang++-12` as the CUDA compiler, the build after CMake configuration produces an error like:
`make[2]: *** No rule to make target 'CMakeFiles/cudalink_exe.dir/exe2.cpp.o', needed by 'CMakeFiles/cudalink_exe.dir/sm_75.cubin'. Stop.`
A reproducer is attached:
[cmake_clang_cuda.tar.gz](/uploads/b684cbd4d4d340d53918ae030a6a92d6/cmake_clang_cuda.tar.gz)
CMake version: 3.21.0
CUDA version: 11.4
Clang version: 12.0.1
OS: Ubuntu 20.043.21.2Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/22647Android: MINGW defined with Clang compiler on Windows host2023-02-06T16:59:59-05:00Ghost UserAndroid: MINGW defined with Clang compiler on Windows hostOriginally filed at https://github.com/android/ndk/issues/1581
The issue is that the compiler ID code that does compiler id (https://gitlab.kitware.com/cmake/cmake/-/blob/v3.21.2/Modules/CMakeDetermineCXXCompiler.cmake#L120-132) does no...Originally filed at https://github.com/android/ndk/issues/1581
The issue is that the compiler ID code that does compiler id (https://gitlab.kitware.com/cmake/cmake/-/blob/v3.21.2/Modules/CMakeDetermineCXXCompiler.cmake#L120-132) does not account for `CMAKE_${lang}_COMPILER_TARGET` so it is only able to identify the default target when using Clang. This means that for a configuration that targets android will identify as MINGW when building on Windows because the _default_ clang target on that host is windows.
Issue-created-by: @danalbert3.22.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22224`CXX_EXTENSIONS OFF` does not turn off extensions in GCC 112021-11-12T09:02:45-05:00Pedro Fonini`CXX_EXTENSIONS OFF` does not turn off extensions in GCC 11Using CMake 3.20.2; this has been described here: https://stackoverflow.com/questions/67641124/gcc-11-how-to-tell-cmake-i-dont-want-the-default-c-gnu-extensions
GCC 11's default ISO C++ standard is C++17, so that when I declare `target_...Using CMake 3.20.2; this has been described here: https://stackoverflow.com/questions/67641124/gcc-11-how-to-tell-cmake-i-dont-want-the-default-c-gnu-extensions
GCC 11's default ISO C++ standard is C++17, so that when I declare `target_compile_features(mytarget cxx_std_17)` CMake (correctly) does not generate any `-std` flag. However, GCC's default is actually `-std=gnu++17`, and if I want `-std=c++17` I should be able to declare `set_target_properties(mytarget PROPERTIES CXX_EXTENSIONS OFF)`. Unfortunately, this has no effect, and CMake still omits the `-std` flag.3.22.0Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/23269macOS: CMake may generate invalid static libraries using Clang2023-11-28T17:21:53-05:00Saleem AbdulrasoolmacOS: CMake may generate invalid static libraries using ClangWhen `llvm-ar` is available in `PATH`, CMake will prefer that over `ar` (assuming a LLVM based toolchain IIRC). On Darwin platforms, there is no `llvm-ar` available by default so this is unlikely to occur. However, should it occur, the...When `llvm-ar` is available in `PATH`, CMake will prefer that over `ar` (assuming a LLVM based toolchain IIRC). On Darwin platforms, there is no `llvm-ar` available by default so this is unlikely to occur. However, should it occur, the use of a different librarian causes issues as `llvm-ar` does not generate a symbol table which `ld64` deems cromulent. Attempting to link with the resulting library will fail with an obscure error message:
```
ld: warning: ignoring file ..., building for macOS-x86_64 but attempting to link with file built for macOS-x86_64
```
Ideally, we should be using `libtool` to generate the static library on Darwin as that is the officially supported librarian in cctools.3.21.6Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22905Clang: CMake generates -flto instead of -flto=thin on Windows2021-11-16T09:06:14-05:00Robin ChristClang: CMake generates -flto instead of -flto=thin on WindowsOn Windows, CMake incorrectly generates
```
-O3 -DNDEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -O3 -fno-math-errno -flto -fvisibility-inlines-hidden -march=core-avx2
```
On Linux we get the expected result
```
-O3 -DNDEBUG -O3 -fno...On Windows, CMake incorrectly generates
```
-O3 -DNDEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -O3 -fno-math-errno -flto -fvisibility-inlines-hidden -march=core-avx2
```
On Linux we get the expected result
```
-O3 -DNDEBUG -O3 -fno-math-errno -flto=thin -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -march=core-avx2
```
(dumped via `CMAKE_EXPORT_COMPILE_COMMANDS`)
If I read the CMake source correctly, that is not supposed to happen?
```
cmake version 3.22.0-rc2
```
```
clang version 12.0.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
```
`ninja 1.10.2`
Compiler is recognised as
```
-- The C compiler identification is Clang 12.0.1 with GNU-like command-line
-- The CXX compiler identification is Clang 12.0.1 with GNU-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/LLVM/bin/clang.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/LLVM/bin/clang++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
```
LTO is enabled via `set(CMAKE_INTERPROCEDURAL_OPTIMIZATION TRUE)`3.23.0Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/22860CUDA: Support CUDA_ARCHITECTURES all and all-major on Clang and older NVCC2022-02-02T08:23:22-05:00Raul Tambreraul@tambre.eeCUDA: Support CUDA_ARCHITECTURES all and all-major on Clang and older NVCCWe need only detect the CUDA toolkit version and then maintain lists for each one's support versions. Shouldn't be too difficult, though spelunking for the older releases might be difficult.We need only detect the CUDA toolkit version and then maintain lists for each one's support versions. Shouldn't be too difficult, though spelunking for the older releases might be difficult.3.23.0Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.ee