CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-02-22T08:24:24-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25590cxxmodules: clang-scan-deps needs -resource-dir when cross compiling2024-02-22T08:24:24-05:00Shuang Liucxxmodules: clang-scan-deps needs -resource-dir when cross compilingwith the latest cmake 3.28 with module support enabled, when cross compiling with clang, it's better to supply the rsult of `clang++ -print-resource-dir` as `-resource-dir` otherwise might run into this:
https://clang.llvm.org/docs/Stand...with the latest cmake 3.28 with module support enabled, when cross compiling with clang, it's better to supply the rsult of `clang++ -print-resource-dir` as `-resource-dir` otherwise might run into this:
https://clang.llvm.org/docs/StandardCPlusPlusModules.html#possible-issues-failed-to-find-system-headers3.28.4Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/25511Issue with C++ modules and gcc2024-02-16T09:33:23-05:00FVIssue with C++ modules and gccHello, the following behaves as expected with clang but not with gcc trunk.
I had a look at what ninja is doing but I am not able to figure out if this a ninja or cmake or gcc issue.
CMakeLists.txt:
```
cmake_minimum_required(VERSION 3....Hello, the following behaves as expected with clang but not with gcc trunk.
I had a look at what ninja is doing but I am not able to figure out if this a ninja or cmake or gcc issue.
CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.28) # With 3.28, no need for set(CMAKE_CXX_SCAN_FOR_MODULES ON).
project(std_module_example CXX)
set(CMAKE_CXX_STANDARD 20)
# Default to C++ extensions being off. Clang's modules support have trouble
# with extensions right now and it is not required for any other compiler
set(CMAKE_CXX_EXTENSIONS OFF)
add_library(foo)
target_sources(foo
PRIVATE
foo_impl.cxx
PUBLIC
FILE_SET cxx_modules TYPE CXX_MODULES FILES
foo.cxx
)
add_executable(hello main.cxx)
target_link_libraries(hello PRIVATE foo)
```
main.cxx:
```
import foo;
int main() {
foo f;
f.helloworld();
return 0;
}
```
foo.cxx:
```
module;
#include <iostream>
export module foo;
export class foo {
public:
foo();
~foo();
void helloworld();
};
export void fun() {
std::cout << "abc" << std::endl;
}
```
foo_impl.cxx:
```
module; // Start of the globl module fragment where #includes can happen
#include <iostream>
module foo;
foo::foo() = default;
foo::~foo() = default;
void foo::helloworld() { std::cout << "hello worldad \n"; }
```
The issue is that the second ninja invocation below rebuilds main.o and foo.o with gcc (clang handles this correctly):
```
rm -rf CMakeFiles/ CMakeCache.txt build.ninja libfoo.a hello cmake_install.cmake
cmake -DCMAKE_BUILD_TYPE=Debug -GNinja
ninja
touch foo_impl.cxx
ninja -v -d explain
```
Versions:
```
cmake --version
cmake version 3.28.0
ninja --version
1.12.0.git
# Build from source...
g++ -v
gcc version 14.0.0 20231211 (experimental) (GCC)
clang -v
clang version 16.0.0
```
I attached the ninja outputs for [clang](/uploads/4693b18c2c2ce07861386d679483c987/clang_build.txt) and [gcc](/uploads/60a4bef80a0fe92cfc79caa5741d3e5a/gcc_build.txt).3.28.4Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/20751Clang CUDA on Windows doesn't build without manual flags and standard paths2024-01-23T14:56:25-05:00Corentin SchreiberClang CUDA on Windows doesn't build without manual flags and standard pathsI have just tried to use CMake 3.17.20200520-g81e8f62 and clang to compile a CUDA project we normally build with nvcc. I bumped into a few issues:
- [x] ~~CMake seems to ignore the ``CMAKE_CUDA_COMPILER_WORKS`` option, so the compiler c...I have just tried to use CMake 3.17.20200520-g81e8f62 and clang to compile a CUDA project we normally build with nvcc. I bumped into a few issues:
- [x] ~~CMake seems to ignore the ``CMAKE_CUDA_COMPILER_WORKS`` option, so the compiler check is always performed.~~ This is [intended](https://gitlab.kitware.com/cmake/cmake/-/issues/20751#note_764869).
- [x] ~~At least during the compiler test, CMake does not seem to forward the ``CMAKE_CUDA_ARCHITECTURES`` values to clang, I have to set it manually using ``CMAKE_CUDA_FLAGS=--cuda-gpu-arch=XXX``. Otherwise it tries to compile for ``sm_20``, which apparently my CUDA installation (CUDA 10.1) doesn't support.~~ This was because ``cuda-path`` wasn't set, see below.
- [x] ~~Related to the above, I don't know how to make CMake compile for multiple GPU architectures at once. ``CMAKE_CUDA_ARCHITECTURES`` can contain an array of architectures (since nvcc can compile for multiple architectures at once), but since clang can only compile for one architecture at a time with ``--cuda-gpu-arch``, I cannot build multiple architectures with the trick above.~~ Trick no longer required.
- [x] CMake does not seem to forward the path to the CUDA runtime to clang, I have to set it manually using ``CMAKE_CUDA_FLAGS=--cuda-path=XXX``.
- [x] When linking the test program, the clang linker cannot find the CUDA lib files because the linker include path is set to just ``<CUDA_PATH>/lib`` (which is empty) instead of ``<CUDA_PATH>/lib/x64`` (which contains the 64bit lib files). I copied the lib files manually into the ``lib`` folder.
After that last step, CMake decided the compiler was working.
Then I went on to compile our project, a shared library, in ``CMAKE_BUILD_TYPE=RelWithDebInfo``. Generator is MinGW Makefiles. Compilation went fine, however at link time there were inconsistencies in the runtime libraries being used. CXX files correctly used ``MD_DynamicRelease``, but CU files used ``MT_StaticRelease``. This can be seen below.
With ``VERBOSE=1``, ``mingw32-make`` reports the following CXX compiler command being used:
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE <CUSTOM_PREPROCESSOR> <CUSTOM_INCLUDE_PATHS> -O2 -g -DNDEBUG -Xclang -gcodeview -D_DLL -D_MT -Xclang --dependent-lib=msvcrt <CUSTOM_COMPILER_OPTS> -o <OUTPUT_FILE> -c <CXX_FILE>
```
and the following CU compiler command:
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE <CUSTOM_PREPROCESSOR> <CUSTOM_INCLUDE_PATHS> --cuda-gpu-arch=sm_30 --cuda-path=C:/mingw/cuda --cuda-gpu-arch=sm_30 <CUSTOM_COMPILER_OPTS> -std=gnu++14 -x cuda -c <CUDA_FILE> -o <OUTPUT_FILE>
```
and for the linker:
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -fuse-ld=lld-link -nostartfiles -nostdlib -O2 -g -DNDEBUG -Xclang -gcodeview -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -shared -o <OUTPUT_DLL> -Xlinker /implib:<LIBRARY>.lib -Xlinker /pdb:<LIBRARY>.pdb -Xlinker /version:0.0 <OBJECTS> <LINK_LIBS>
```
Notice how ``-D_DLL -D_MT`` are missing for the CU compilation command, but also other important compilation flags, like ``-O2 -g``. Notice also how there are now two ``--cuda-gpu-arch=sm_30``; I guess one of them is the one I added manually in ``CMAKE_CUDA_FLAGS`` (to make the compiler test pass) and the other was added by CMake somehow.https://gitlab.kitware.com/cmake/cmake/-/issues/20776CUDA: Support Clang on Windows2024-01-23T14:56:21-05:00Raul Tambreraul@tambre.eeCUDA: Support Clang on WindowsCMake must set correct flags on Windows for Clang. Originally reported in #20751.CMake must set correct flags on Windows for Clang. Originally reported in #20751.https://gitlab.kitware.com/cmake/cmake/-/issues/25465C++20 module is broken (missing transitive usage) when the files are listed i...2023-12-06T08:51:25-05:00Tan S. B.C++20 module is broken (missing transitive usage) when the files are listed in a certain orderCMakeLists.txt:
```
cmake_minimum_required(VERSION 3.28.0)
project(MyLib LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 23)
add_library(my-lib)
target_sources(my-lib PRIVATE FILE_SET CXX_MODULES FILES
mod1.cpp
mod3.cpp # import mod2
...CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.28.0)
project(MyLib LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 23)
add_library(my-lib)
target_sources(my-lib PRIVATE FILE_SET CXX_MODULES FILES
mod1.cpp
mod3.cpp # import mod2
mod4.cpp # import mod2
mod2.cpp # import mod1
mod5.cpp # import mod4
mod6.cpp # import mod5
)
```
All module units are empty except for the imports as indicated in the comments above.
When compiling this project against Clang, I got
```
[13/14] Building CXX object CMakeFiles/my-lib.dir/mod6.cpp.o
/mnt/d/test/test-module/mod6.cpp:2:1: warning: it is deprecated to read module 'mod1' implicitly; it is going to be removed in clang 18; consider to specify the dependencies explicitly [-Wread-modules-implicitly]
2 | import mod5;
| ^
1 warning generated.
warning: it is deprecated to read module 'mod1' implicitly; it is going to be removed in clang 18; consider to specify the dependencies explicitly [-Wread-modules-implicitly]
1 warning generated.
```
It seems that CMake forgets to tell Clang the location of `mod1.pcm` when compiling `mod6.cpp`.
Note that the order of files in `target_souces` is significant. The warning might not occur if the files are listed in a different order.
For the reference, here's the project in a zip file: [test-module.zip](/uploads/bd15f05a571c875d3bf1bd5fef844dd7/test-module.zip)3.28.0Namniav WNamniav Whttps://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/25429CMake Error: -E cmake_ninja_dyndep failed to parse CMakeFiles/main.dir/main.c...2023-11-22T07:20:10-05:00Namniav WCMake Error: -E cmake_ninja_dyndep failed to parse CMakeFiles/main.dir/main.cpp.o.ddi: expected 1 source entryRepro steps:
0. Versions
```
$ cmake --version
cmake version 3.28.20231118-gee3e050
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ninja --version
1.11.1
$ clang++ --version
Homebrew clang version 17.0.4
Target: ...Repro steps:
0. Versions
```
$ cmake --version
cmake version 3.28.20231118-gee3e050
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ninja --version
1.11.1
$ clang++ --version
Homebrew clang version 17.0.4
Target: arm64-apple-darwin23.1.0
Thread model: posix
InstalledDir: /opt/homebrew/opt/llvm/bin
```
1. CMakeLists.txt
```cmake
cmake_minimum_required(VERSION 3.28)
project(demo CXX)
set(CMAKE_CXX_EXTENSIONS OFF)
set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
if(MESSING)
add_compile_options(-fsanitize=nosupport)
add_link_options(-fsanitize=nosupport)
endif()
add_executable(main main.cpp) # main.cpp's content is "int main() {}"
```
2. Configure and build without defined `MESSING`. This succeeds as expected.
```
$ rm -rf build
$ CXX=`which clang++` cmake -GNinja -S . -B build && cmake --build build
-- The CXX compiler identification is Clang 17.0.4
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /opt/homebrew/opt/llvm/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done (0.2s)
-- Generating done (0.0s)
-- Build files have been written to: /tmp/cmake-test/build
[4/4] Linking CXX executable main
```
3. Reconfigure and build with defined `MESSING`. This fails as expected.
```
$ cmake -DMESSING=1 build && cmake --build build
-- Configuring done (0.0s)
-- Generating done (0.0s)
-- Build files have been written to: /tmp/cmake-test/build
[1/4] Scanning /tmp/cmake-test/main.cpp for CXX dependencies
FAILED: CMakeFiles/main.dir/main.cpp.o.ddi
"/opt/homebrew/Cellar/llvm/17.0.4/bin/clang-scan-deps" -format=p1689 -- /opt/homebrew/opt/llvm/bin/clang++ -fsanitize=nosupport -std=c++20 -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk -x c++ /tmp/cmake-test/main.cpp -c -o CMakeFiles/main.dir/main.cpp.o -MT CMakeFiles/main.dir/main.cpp.o.ddi -MD -MF CMakeFiles/main.dir/main.cpp.o.ddi.d > CMakeFiles/main.dir/main.cpp.o.ddi
error: unsupported argument 'nosupport' to option '-fsanitize='
Error while scanning dependencies for /tmp/cmake-test/main.cpp:
error: unsupported argument 'nosupport' to option '-fsanitize='
ninja: build stopped: subcommand failed.
```
4. Reconfigure and build without defined `MESSING`. **This fails as UN-expected.**
```
$ cmake -DMESSING=0 build && cmake --build build
-- Configuring done (0.0s)
-- Generating done (0.0s)
-- Build files have been written to: /tmp/cmake-test/build
[1/1] Generating CXX dyndep file CMakeFiles/main.dir/CXX.dd
FAILED: CMakeFiles/main.dir/CXX.dd /tmp/cmake-test/build/CMakeFiles/main.dir/CXXModules.json CMakeFiles/main.dir/main.cpp.o.modmap
/opt/homebrew/Cellar/cmake/HEAD-ee3e050/bin/cmake -E cmake_ninja_dyndep --tdi=CMakeFiles/main.dir/CXXDependInfo.json --lang=CXX --modmapfmt=clang --dd=CMakeFiles/main.dir/CXX.dd @CMakeFiles/main.dir/CXX.dd.rsp
CMake Error: -E cmake_ninja_dyndep failed to parse CMakeFiles/main.dir/main.cpp.o.ddi: expected 1 source entry
CMake Error: -E cmake_ninja_dyndep failed to parse ddi file CMakeFiles/main.dir/main.cpp.o.ddi
ninja: build stopped: subcommand failed.
$ cat build/CMakeFiles/main.dir/main.cpp.o.ddi
{
"revision": 0,
"rules": [],
"version": 1
}
```
5. After `cmake --build build --target clean`, it succeeds as expected.
```
$ cmake --build build --target clean && cmake --build build
[1/1] Cleaning all built files...
Cleaning... 8 files.
[4/4] Linking CXX executable main
$ cat build/CMakeFiles/main.dir/main.cpp.o.ddi
{
"revision": 0,
"rules": [
{
"primary-output": "CMakeFiles/main.dir/main.cpp.o"
}
],
"version": 1
}
```
Edited: fixed wrong copied command output.3.28.0Ben BoeckelBen Boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/24235Clang on Windows does not show color diagnostics unless -fansi-escape-codes i...2023-10-23T12:06:38-04:00Alvin WongClang on Windows does not show color diagnostics unless -fansi-escape-codes is addedOn Windows, setting both environment variables `CMAKE_COLOR_DIAGNOSTICS=1` and `CLICOLOR_FORCE=1` still doesn't get Clang to output diagnostics in color. The only way I managed to get color output out of it is to add `-fansi-escape-codes...On Windows, setting both environment variables `CMAKE_COLOR_DIAGNOSTICS=1` and `CLICOLOR_FORCE=1` still doesn't get Clang to output diagnostics in color. The only way I managed to get color output out of it is to add `-fansi-escape-codes` to the C/CXX flags. I tested two different scenarios:
- Windows console (cmd.exe) + ninja + [llvm-mingw](https://github.com/mstorsjo/llvm-mingw)
- GitHub Actions Windows runner + mingw32-make + llvm-mingw
I am not sure if this counts as a CMake issue or Clang's, but Clang always uses the Windows console API by default unless -fansi-escape-codes is given, and I guess it doesn't have direct access to the Windows console when run under make or ninja.https://gitlab.kitware.com/cmake/cmake/-/issues/23305Clang/Windows: Race when using `cmake -E vs_link_exe` with llvm-mt2023-08-17T10:26:12-04:00Haowei WuClang/Windows: Race when using `cmake -E vs_link_exe` with llvm-mtI am debugging a weird llvm test failures in our builder which popped up a few month ago, which is caused by the fact that an executable generated during llvm's cmake configuration step could not be executed, so the tests won't get the c...I am debugging a weird llvm test failures in our builder which popped up a few month ago, which is caused by the fact that an executable generated during llvm's cmake configuration step could not be executed, so the tests won't get the correct error string on Windows. An example test failure can seen [https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-windows-x64/b8832262407257821617/overview](https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-windows-x64/b8832262407257821617/overview) after cmake switched to llvm-mt by default in patch [https://github.com/Kitware/CMake/commit/b12aec6c8daa3e087e6d0fa0441f59622251eb46](https://github.com/Kitware/CMake/commit/b12aec6c8daa3e087e6d0fa0441f59622251eb46). At first I thought it was a llvm-mt.exe bug. But after I managed to generate a minimal reproducer, it seems to be an issue with cmake's vs_link_exe feature.
How to reproduce the issue:
* Install Visual Studio, make sure Windows SDK 10 is also installed (I tested both VS2019 and VS2022, the free community version is OK).
* Build Clang/LLVM for windows (or you can use the [one](https://chrome-infra-packages.appspot.com/p/fuchsia/third_party/clang/windows-amd64/+/integration) built from our builders. You might have to manually symlink `clang-cl.exe`, `clang++.exe` to `clang.exe` and `lld-link.exe` to `lld.exe` as some ZIP program does not process symlinks on windows correctly)
* Build CMake (or use the prebuilt from [https://cmake.org/download/](https://cmake.org/download/), I used `cmake-3.23.0-rc2-windows-x86_64.zip`)
* Download the reproducer `llvm-mt-reproduce.zip` from this ticket and extract it.
* Assuming clang-cl.exe is placed under `C:\src\clang\windows-amd64\bin` and cmake.exe is placed under `C:\src\cmake-3.23.0-rc2-windows-x86_64\bin`, open `x64 Native Tools Command Prompt for VS` from the start menu.
* Navigate to the directory that contains the extracted files from the reproducer package, run:
```
C:\src\llvm-mt-reproduce>run-with-cmake.bat
...
C:\src\llvm-mt-reproduce>out\getErrc.exe
Access is denied.
C:\src\llvm-mt-reproduce>
```
The `getErrc.exe` is a program generated during llvm's cmake configuration step to extract the correct error message string for llvm's unit tests. When this step fails, all error message related unit test will fail, causing the test failures we saw on our builders. The content of the batch file used in the reproducer package is listed as follow:
```
SETLOCAL
set CLANG_CL_PATH=C:\src\clang\windows-amd64\bin\clang-cl.exe
set CMAKE_PATH=C:\src\cmake-3.23.0-rc2-windows-x86_64\bin\cmake.exe
set MT_PATH=C:\src\clang\windows-amd64\bin\llvm-mt.exe
::set MT_PATH="C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\mt.exe"
set RC_PATH="C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\rc.exe"
::set RC_PATH=C:\src\clang\windows-amd64\bin\llvm-rc.exe
set LINKER_PATH=C:\src\clang\windows-amd64\bin\lld-link.exe
%CLANG_CL_PATH% /nologo -TP /DWIN32 /D_WINDOWS /Zc:inline /Zc:__cplusplus /Zc:strictStrings /Oi /Zc:rvalueCast /Brepro /bigobj /W4 -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough -Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wsuggest-override -Wstring-conversion -Wmisleading-indentation /Gw -no-canonical-prefixes /MDd /Zi /Ob0 /Od /RTC1 -std:c++14 /showIncludes /Foout\getErrc.cpp.obj /Fdout\ -c -- .\getErrc.cpp
%CMAKE_PATH% -E vs_link_exe --intdir=out --rc=%RC_PATH% --mt=%MT_PATH% --manifests -- %LINKER_PATH% /nologo out\getErrc.cpp.obj /out:out\getErrc.exe /implib:out\getErrc.lib /pdb:out\getErrc.pdb /version:0.0 /machine:x64 /STACK:10000000 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
```
You can change the paths in `run-with-cmake.bat` file if your paths does not match mine.
On my machine, the `getErrc.exe` generated from cmake's vs_link step cannot be executed and will always result in "this app cannot run on your PC" error and "Access is denied" will be printed to the cmd. How ever, if you run `run-with-cmake.bat` again (to be precise, to run the `cmake -E vs_link_exe ...` from the batch file), the `out\getErrc.exe` generated by the 2nd run will work without any issues:
```
C:\src\llvm-mt-reproduce> C:\src\cmake-3.23.0-rc2-windows-x86_64\bin\cmake.exe -E vs_link_exe --intdir=out --rc="C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\rc.exe" --mt=C:\src\clang\windows-amd64\bin\llvm-mt.exe --manifests -- C:\src\clang\windows-amd64\bin\lld-link.exe /nologo out\getErrc.cpp.obj /out:out\getErrc.exe /implib:out\getErrc.lib /pdb:out\getErrc.pdb /version:0.0 /machine:x64 /STACK:10000000 /debug /INCREMENTAL /subsystem:console kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib
C:\src\llvm-mt-reproduce>out\getErrc.exe
no such file or directory;is a directory;invalid argument;permission denied
C:\src\llvm-mt-reproduce>
```
So it make me suspect that there might be an data race issue here. When the `cmake -E vs_link_exe ...` was invoked the first time, an incomplete manifest file that was still being written might have been present to the linker and embedded to the final getErrc.exe, causing the error messages we saw. When running the command twice, the manifest file were already correctly generated, so this time the executable has the correct manifest file embedded. If this is the case, I think this is a bug on cmake side and should be fixed.
A few other observations:
1. When I add `--trace` flag to the `cmake -E vs_link_exe ...` (so final command line looks like ) to get the command traces, the original successful cmake invocation will result in error with messages:
```
Running with trace output on.
CMake Warning:
Ignoring extra path from command line:
"advapi32.lib"
CMake Error: Unknown argument --
CMake Error: Run 'cmake --help' for all supported options.
```
Is it a cmake flag parser bug? I have to use Windows audit mode to record the command line flags in order to debug this failure.
2. The feature currently implemented by llvm-mt is very limited (only `/manifest` and `/out` flags are implemented, others are not) compared to the original `mt.exe` provided by Windows MSVC. Is it too early for cmake to set llvm-mt by default on Windows? Can we switch it back to the `mt.exe`?
[llvm-mt-reproduce.zip](/uploads/69d0304ac7ee24a2db6502f1eb480820/llvm-mt-reproduce.zip)3.21.7Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22217Support depfiles for ELF linkers2023-05-04T09:06:27-04:00Ben BoeckelSupport depfiles for ELF linkers`lld` and (newer) `ld.bfd` and `ld.gold` support a `--dependency-file=` flag to dump out depfiles. We should hook this up in the Ninja and Makefiles generators.
See [this message on the `gn-dev` list](https://groups.google.com/a/chromiu...`lld` and (newer) `ld.bfd` and `ld.gold` support a `--dependency-file=` flag to dump out depfiles. We should hook this up in the Ninja and Makefiles generators.
See [this message on the `gn-dev` list](https://groups.google.com/a/chromium.org/g/gn-dev/c/sN09GYS1ufE/m/D5p9tl8QAwAJ).
Cc: @kyle.edwards @brad.king @marc.chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/24601install(TARGETS): Uses llvm-strip incorrectly on Apple platforms2023-03-31T08:02:23-04:00Dmitry Babokininstall(TARGETS): Uses llvm-strip incorrectly on Apple platformsI’m enabling `CPACK_STRIP_FILES` on macOS and I have manually built llvm toolchain in the path (same is reproducible with official LLVM build - https://github.com/llvm/llvm-project/releases/download/llvmorg-15.0.7/clang+llvm-15.0.7-x86_6...I’m enabling `CPACK_STRIP_FILES` on macOS and I have manually built llvm toolchain in the path (same is reproducible with official LLVM build - https://github.com/llvm/llvm-project/releases/download/llvmorg-15.0.7/clang+llvm-15.0.7-x86_64-apple-darwin21.0.tar.xz) and CPack finds `llvm-strip` instead of `strip` (which can be picked up either at `/usr/bin/strip` or in the SDK). As a result, I have the following message when building the a package:
`/Users/dybaboki/tmp/clang+llvm-15.0.7-x86_64-apple-darwin21.0/bin/llvm-strip: error: unknown argument '-u'`
Note that the build is “successful”, i.e. CPack ignores this error.
Seems that CPack needs to treat llvm-strip differently, i.e. take into account that `-u` is not supported. Alternatively `llvm-strip` should not be selected as a strip tool, as `strip` is always available (as a system tool or in SDK).
Also if stripping has fail, packaging needs to fail (whatever tool is used) rather than ignore it.
The issue was originally reported on Discourse [here](https://discourse.cmake.org/t/cpack-strip-doesnt-work-with-llvm-strip-on-macos/7671)3.27.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24611Clang 16 on Windows for C++20 modules2023-03-21T08:58:47-04:00huangqinjinClang 16 on Windows for C++20 modules### Information
- CMake: 3.26.0
- Ninja: 1.11.0
- Clang: 16.0.0
- OS: Windows 10
Tests a simple program at https://github.com/huangqinjin/cxxmodules/tree/master/named-module.
### Issue 1
```
C:/Program Files/LLVM/bin/clang-scan-deps.ex...### Information
- CMake: 3.26.0
- Ninja: 1.11.0
- Clang: 16.0.0
- OS: Windows 10
Tests a simple program at https://github.com/huangqinjin/cxxmodules/tree/master/named-module.
### Issue 1
```
C:/Program Files/LLVM/bin/clang-scan-deps.exe -format=p1689 -- C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -O0 -std=gnu++20 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -g -Xclang -gcodeview -x c++ C:/Users/huangqinjin/Projects/cxxmodules/named-module/hello.cppm -c -o named-module\CMakeFiles\named-module.dir\hello.cppm.obj -MT named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi -MD -MF named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi.d > named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi
error: no such file or directory: '>'
error: no such file or directory: 'named-module\CMakeFiles\named-module.dir\hello.cppm.obj.ddi'
```
The stdout redirection cannot be used here.
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.26.0/Modules/Compiler/Clang-CXX.cmake#L42
### Issue 2 (After bypass issue 1)
Generated a strange BMI file `named-moduleCMakeFilesnamed-module.dirhello.pcm` in cmake binary dir.
The conetent of the response file `named-module\CMakeFiles\named-module.dir\hello.cppm.obj.modmap` is
```
-x c++-module
-fmodule-output=named-module\CMakeFiles\named-module.dir\hello.pcm
```
Seems to me that clang does not support back slash.
### Issue 3
```
C:\PROGRA~1\LLVM\bin\CLANG_~1.EXE -O0 -std=gnu++20 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -g -Xclang -gcodeview -MD -MT named-module/CMakeFiles/named-module.dir/main.cpp.obj -MF named-module\CMakeFiles\named-module.dir\main.cpp.obj.d @named-module\CMakeFiles\named-module.dir\main.cpp.obj.modmap -o named-module/CMakeFiles/named-module.dir/main.cpp.obj -c C:/Users/huangqinjin/Projects/cxxmodules/named-module/main.cpp
C:/Users/huangqinjin/Projects/cxxmodules/named-module/main.cpp:1:8: fatal error: module 'hello' not found
```
After investigation, clang C++20 module only supports `-std=c++20`, `-std=gnu++20` is not supported currently. So
`set(CMAKE_CXX_EXTENSIONS OFF)` is required.3.26.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24585CUDA: configure error with Clang 152023-03-13T14:33:41-04:00Jakub KlinkovskýCUDA: configure error with Clang 15I have a minimal `CMakeLists.txt` project with native CUDA and clang compiler:
```cmake
cmake_minimum_required(VERSION 3.25.3)
set(CMAKE_CUDA_COMPILER clang++)
set(CMAKE_CUDA_ARCHITECTURES 61)
project(foo LANGUAGES CUDA)
add_executable(f...I have a minimal `CMakeLists.txt` project with native CUDA and clang compiler:
```cmake
cmake_minimum_required(VERSION 3.25.3)
set(CMAKE_CUDA_COMPILER clang++)
set(CMAKE_CUDA_ARCHITECTURES 61)
project(foo LANGUAGES CUDA)
add_executable(foo foo.cu)
```
When I try to build it, I'm getting this error:
```
$ cmake -B build -S . -G Ninja
-- The CUDA compiler identification is unknown
-- Check for working CUDA compiler: /usr/bin/clang++
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
_CMAKE_CUDA_WHOLE_FLAG
CMake Error at /usr/share/cmake/Modules/CMakeTestCUDACompiler.cmake:89 (try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
CMakeLists.txt:4 (project)
-- Configuring incomplete, errors occurred!
See also "/home/lahwaacz/foo/build/CMakeFiles/CMakeOutput.log".
See also "/home/lahwaacz/foo/build/CMakeFiles/CMakeError.log".
```
The `CMakeError.log` file contains:
```
Checking whether the CUDA compiler is NVIDIA using "" did not match "nvcc: NVIDIA \(R\) Cuda compiler driver":
clang version 15.0.7
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Checking whether the CUDA compiler is NVIDIA using "" did not match "nvcc: NVIDIA \(R\) Cuda compiler driver":
clang-15: error: no input files
Checking whether the CUDA compiler is Clang using "" did not match "(clang version)":
clang-15: error: no input files
Checking whether the CUDA compiler is NVIDIA using "" did not match "nvcc: NVIDIA \(R\) Cuda compiler driver":
clang-15: error: no input files
Checking whether the CUDA compiler is Clang using "" did not match "(clang version)":
clang-15: error: no input files
```
The platform is Arch Linux:
- clang 15.0.7-1
- cmake 3.25.3-1
- cuda 12.1.0-1
I don't know what the errors mean and where to start looking. Do you have any hints?https://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/23066Clang: duplicate resource: type MANIFEST for GNU Windows build2022-07-20T09:09:39-04:00djdronClang: duplicate resource: type MANIFEST for GNU Windows buildRelated to #22611.
As described in [this note](https://gitlab.kitware.com/cmake/cmake/-/issues/22611#note_1098039)Related to #22611.
As described in [this note](https://gitlab.kitware.com/cmake/cmake/-/issues/22611#note_1098039)https://gitlab.kitware.com/cmake/cmake/-/issues/23664RunCMake.CXXModules fails on Debian_Unstable-Clang-libcxx2022-06-28T12:38:13-04:00Raul Tambreraul@tambre.eeRunCMake.CXXModules fails on Debian_Unstable-Clang-libcxxContinuation of https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7224#note_1207856
---
[Example failure](https://open.cdash.org/test/735088553)
The vendored Clang used by the bot is built with `-DCLANG_DEFAULT_STD_C=c2x -DCLANG...Continuation of https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7224#note_1207856
---
[Example failure](https://open.cdash.org/test/735088553)
The vendored Clang used by the bot is built with `-DCLANG_DEFAULT_STD_C=c2x -DCLANG_DEFAULT_STD_CXX=cxx2b`, i.e. it defaults C20 and C++23 without GNU extensions.
Cc @ben.boeckel3.25.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.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/22611Clang: *.manifest files listed as sources are ignored by GNU-like front-end o...2022-01-31T13:03:18-05:00Nick HutchinsonClang: *.manifest files listed as sources are ignored by GNU-like front-end on WindowsWhen building with clang (not clang-cl) on Windows, *.manifest files listed as sources for an executable or dll target are not embedded into the executable or dll.
Ideally, CMake would add something like the following to the link line:
...When building with clang (not clang-cl) on Windows, *.manifest files listed as sources for an executable or dll target are not embedded into the executable or dll.
Ideally, CMake would add something like the following to the link line:
-Xlinker /MANIFEST:EMBED -Xlinker /MANIFESTINPUT:manifest1.manifest -Xlinker /MANIFESTINPUT:manifest2.manifest ...
## To reproduce
Compare the link lines generated by the following project with CMAKE_CXX_COMPILER=clang-cl.exe vs CMAKE_CXX_COMPILER=clang++.exe. (I'm assuming a Ninja generator.)
With clang-cl, the manifest file is respected -- the link is performed via `cmake.exe -E vs_link_exe`, which appears to embed the manifests via mt.exe. With clang++, the manifest file is ignored.
**CMakeLists.txt**
```cmake
cmake_minimum_required(VERSION 3.21)
project(TestProj CXX)
add_executable(my_exe my_exe.cpp compatibility.manifest)
```
**my_exe.cpp**
```cpp
int main() { return 0; }
```
**compatibility.manifest**
```xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--The ID below indicates application support for Windows 10 -->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
</application>
</compatibility>
</assembly>
```
Tested with CMake 3.21.2, LLVM 11.0.0, MSVC 19.29, Ninja 1.10.2
## Workaround
Add the linker args manually:
```cmake
if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" AND MSVC_VERSION AND NOT MSVC)
target_link_options(my_exe PRIVATE
"LINKER:/MANIFEST:EMBED"
"LINKER:/MANIFESTINPUT:${CMAKE_CURRENT_SOURCE_DIR}/compatibility.manifest"
)
endif ()
```https://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/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.ee