CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-11-10T01:06:46-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/21453gtest_discover_tests does not honor environment property when running the tes...2023-11-10T01:06:46-05:00Ted Giblettegtest_discover_tests does not honor environment property when running the test executable with the --gtest-list-tests commandThe gtest_discover_tests function does not work on Windows whenever the test executable has some dependency on a shared library because it is currently not possible to set the environment path for the call to the test executable with the...The gtest_discover_tests function does not work on Windows whenever the test executable has some dependency on a shared library because it is currently not possible to set the environment path for the call to the test executable with the --gtest-list-tests command. The test executable will get built but the final step of calling the test executable with the --gtest-list-tests command will fail, causing the ctests to not get generated and the overall build to fail. This is not an issue on Linux because the rpath is set on the test executable and the shared libraries are found.https://gitlab.kitware.com/cmake/cmake/-/issues/21366PCH: Build fails in case-sensitive folder on Windows (VS2019)2021-11-05T05:02:01-04:00yuryburaPCH: Build fails in case-sensitive folder on Windows (VS2019)Starting with Windows 10 build 17093, Microsoft introduced a new way to handle case sensitive files in Windows: per-directory case sensitivity. Microsoft uses this ability in the Windows Subsystem for Linux to give you better interoperab...Starting with Windows 10 build 17093, Microsoft introduced a new way to handle case sensitive files in Windows: per-directory case sensitivity. Microsoft uses this ability in the Windows Subsystem for Linux to give you better interoperability when using case sensitive files, and you can also use it yourself with regular Windows applications. As of Windows 10 build 17110, this behavior is the default.
CMake generates solution for VS2019 without any errors in the build folder with case-sensitive attribute.
But build fails when I enable precompiled headers:
```
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): warning MSB8064: Custom build for item "D:\libs\test\test_pch\build\CMakeFiles\3b418ecacecbd793e2c2f33a71c236
cd\generate.stamp.rule" succeeded, but specified dependency "d:\libs\test\test_pch\build\cmakefiles\3b418ecacecbd793e2c2f33a71c236cd\generate.stamp.rule" does not exist. This may cause incremental build to work incorrectly. [D:\libs\tes
t\test_pch\build\ZERO_CHECK.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): warning MSB8064: Custom build for item "D:\libs\test\test_pch\build\CMakeFiles\3b418ecacecbd793e2c2f33a71c236
cd\generate.stamp.rule" succeeded, but specified dependency "d:\libs\test\test_pch\build\cmakefiles\3.17.1\cmakeccompiler.cmake" does not exist. This may cause incremental build to work incorrectly. [D:\libs\test\test_pch\build\ZERO_CHE
CK.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): warning MSB8064: Custom build for item "D:\libs\test\test_pch\build\CMakeFiles\3b418ecacecbd793e2c2f33a71c236
cd\generate.stamp.rule" succeeded, but specified dependency "d:\libs\test\test_pch\build\cmakefiles\3.17.1\cmakecxxcompiler.cmake" does not exist. This may cause incremental build to work incorrectly. [D:\libs\test\test_pch\build\ZERO_C
HECK.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): warning MSB8064: Custom build for item "D:\libs\test\test_pch\build\CMakeFiles\3b418ecacecbd793e2c2f33a71c236
cd\generate.stamp.rule" succeeded, but specified dependency "d:\libs\test\test_pch\build\cmakefiles\3.17.1\cmakerccompiler.cmake" does not exist. This may cause incremental build to work incorrectly. [D:\libs\test\test_pch\build\ZERO_CH
ECK.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): warning MSB8064: Custom build for item "D:\libs\test\test_pch\build\CMakeFiles\3b418ecacecbd793e2c2f33a71c236
cd\generate.stamp.rule" succeeded, but specified dependency "d:\libs\test\test_pch\build\cmakefiles\3.17.1\cmakesystem.cmake" does not exist. This may cause incremental build to work incorrectly. [D:\libs\test\test_pch\build\ZERO_CHECK.
vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): warning MSB8065: Custom build for item "D:\libs\test\test_pch\build\CMakeFiles\3b418ecacecbd793e2c2f33a71c236
cd\generate.stamp.rule" succeeded, but specified output "d:\libs\test\test_pch\build\cmakefiles\generate.stamp" has not been created. This may cause incremental build to work incorrectly. [D:\libs\test\test_pch\build\ZERO_CHECK.vcxproj]
Building Custom Rule D:/libs/test/test_pch/CMakeLists.txt
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): warning MSB8064: Custom build for item "D:\libs\test\test_pch\CMakeLists.txt" succeeded, but specified depend
ency "d:\libs\test\test_pch\build\cmakefiles\3.17.1\cmakeccompiler.cmake" does not exist. This may cause incremental build to work incorrectly. [D:\libs\test\test_pch\build\test_exe.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): warning MSB8064: Custom build for item "D:\libs\test\test_pch\CMakeLists.txt" succeeded, but specified depend
ency "d:\libs\test\test_pch\build\cmakefiles\3.17.1\cmakecxxcompiler.cmake" does not exist. This may cause incremental build to work incorrectly. [D:\libs\test\test_pch\build\test_exe.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): warning MSB8064: Custom build for item "D:\libs\test\test_pch\CMakeLists.txt" succeeded, but specified depend
ency "d:\libs\test\test_pch\build\cmakefiles\3.17.1\cmakerccompiler.cmake" does not exist. This may cause incremental build to work incorrectly. [D:\libs\test\test_pch\build\test_exe.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): warning MSB8064: Custom build for item "D:\libs\test\test_pch\CMakeLists.txt" succeeded, but specified depend
ency "d:\libs\test\test_pch\build\cmakefiles\3.17.1\cmakesystem.cmake" does not exist. This may cause incremental build to work incorrectly. [D:\libs\test\test_pch\build\test_exe.vcxproj]
C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(234,5): warning MSB8065: Custom build for item "D:\libs\test\test_pch\CMakeLists.txt" succeeded, but specified output
"d:\libs\test\test_pch\build\cmakefiles\generate.stamp" has not been created. This may cause incremental build to work incorrectly. [D:\libs\test\test_pch\build\test_exe.vcxproj]
cmake_pch.cxx
D:\libs\test\test_pch\build\CMakeFiles\test_exe.dir\cmake_pch.cxx : fatal error C1083: Cannot open compiler intermediate file: 'd:\libs\test\test_pch\build\test_exe.dir\debug\cmake_pch.pch': No such file or directory [D:\libs\test\test_
pch\build\test_exe.vcxproj]
```
Please find attached minimum example: [test_pch.zip](/uploads/b2decf4ba1d9ea2e9a34e063bbc85e4c/test_pch.zip)
To reproduce this error please unpack attached archive and run build_cs.bat.https://gitlab.kitware.com/cmake/cmake/-/issues/21291Crosscompiling on Windows system escapes $ORIGIN for INSTALL_RPATH2021-04-04T07:40:45-04:00Tobias WilkerCrosscompiling on Windows system escapes $ORIGIN for INSTALL_RPATHI am cross-compiling for a Linux system on my Windows machine. I need to set the RPATH property to $ORIGIN. For that I use the following code.
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH "\$ORIGIN")`
What I get is \\$OR...I am cross-compiling for a Linux system on my Windows machine. I need to set the RPATH property to $ORIGIN. For that I use the following code.
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH "\$ORIGIN")`
What I get is \\$ORIGIN.
![RPATH](/uploads/973e641145b1ab891f15d22eebabbe41/RPATH.PNG)
I also tried different ways to escape the $ sign
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH "$ORIGIN")` -> \\$ORIGIN
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH $ORIGIN)` -> \\$ORIGIN
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH \$ORIGIN)` -> \\$ORIGIN
`set_target_properties(LibraryName PROPERTIES INSTALL_RPATH "\\\$ORIGIN")` -> \\\\\\$ORIGIN
When I cross-compile the same project using a Linux machine, than it works. Meaning "\\$ORIGIN" -> $ORIGIN.https://gitlab.kitware.com/cmake/cmake/-/issues/21257FindMPI: Cannot find MSMPI for Fortran2022-12-13T08:26:39-05:00Tetsuya MishimaFindMPI: Cannot find MSMPI for FortranThe CMake 3.18 findMPI on Windows 10 can’t find MS-MPI for Fortran. After some investigations, I found that this patch fixed the problem:
```patch
FindMPI.cmake Thu Aug 20 08:20:32 2020
FindMPI.cmake-p1 Wed Sep 30 11:10:26 2020
********...The CMake 3.18 findMPI on Windows 10 can’t find MS-MPI for Fortran. After some investigations, I found that this patch fixed the problem:
```patch
FindMPI.cmake Thu Aug 20 08:20:32 2020
FindMPI.cmake-p1 Wed Sep 30 11:10:26 2020
***************
*** 1091,1096 ****
--- 1091,1101 ----
if(MPI_${LANG}_INCLUDE_DIRS)
list(REMOVE_DUPLICATES MPI_${LANG}_INCLUDE_DIRS)
endif()
+ if(MPI_${LANG}_ADDITIONAL_INCLUDE_VARS)
+ foreach(MPI_ADDITIONAL_INC_DIR IN LISTS MPI_${LANG}_ADDITIONAL_INCLUDE_VARS)
+ list(APPEND MPI_${LANG}_INCLUDE_DIRS "${MPI_${MPI_ADDITIONAL_INC_DIR}_INCLUDE_DIR}")
+ endforeach()
+ endif()
endmacro()
macro(_MPI_split_include_dirs LANG)
```
Regards,
Tetsuya Mishimahttps://gitlab.kitware.com/cmake/cmake/-/issues/21248ARMcc/ARMlink - Wrong link libraries flag is generated on Windows2020-10-05T05:25:26-04:00yann suisiniARMcc/ARMlink - Wrong link libraries flag is generated on WindowsHi,
Using armcc/armlink , if I'm trying to link an existing lib using `target_link_libraries()`
the command `armlink.exe test.o -l sample.lib` is generated instead of
`armlink.exe test.o sample.lib`. ARMlink throws an error .
If you're ...Hi,
Using armcc/armlink , if I'm trying to link an existing lib using `target_link_libraries()`
the command `armlink.exe test.o -l sample.lib` is generated instead of
`armlink.exe test.o sample.lib`. ARMlink throws an error .
If you're looking at the the linker doc, no flag is expected when provided objects files (lib or .o) :
https://developer.arm.com/documentation/dui0474/m/overview-of-the-linker/linker-command-line-syntax?lang=enhttps://gitlab.kitware.com/cmake/cmake/-/issues/21202Unresolved WinMain error in Unicode MFC application built with CMake using Ni...2020-09-17T12:03:41-04:00Romain DeterreUnresolved WinMain error in Unicode MFC application built with CMake using Ninja generatorI had originally asked this question on [Stack Overflow](https://stackoverflow.com/q/63924292/1857952) but got told that it may be a bug with CMake. The problem is a linking error that appears when building a Unicode MFC application usin...I had originally asked this question on [Stack Overflow](https://stackoverflow.com/q/63924292/1857952) but got told that it may be a bug with CMake. The problem is a linking error that appears when building a Unicode MFC application using the Ninja generator. Here is a minimal project that shows this issue. It consists of two files: CMakeLists.txt and hellomfc.cpp.
``` cmake
# CMakeLists.txt
cmake_minimum_required(VERSION 3.18)
project(HelloMFC)
set(CMAKE_MFC_FLAG 2)
add_executable(HelloMFC WIN32 hellomfc.cpp)
target_compile_definitions(HelloMFC PRIVATE _AFXDLL _UNICODE UNICODE)
```
``` c++
// hellomfc.cpp
#include <afxwin.h>
class CMainFrame : public CFrameWnd {
public:
CMainFrame() { Create(NULL, _T("Windows App")); }
};
class CApp : public CWinApp {
CMainFrame *Frame;
BOOL InitInstance() {
Frame = new CMainFrame();
m_pMainWnd = Frame;
Frame->ShowWindow(SW_SHOW);
Frame->UpdateWindow();
return TRUE;
}
};
CApp theApp;
```
For this example, I'm running CMake from a developer command prompt for Visual Studio 2019. Building this using the visual studio 2019 generator works no problem:
<details>
<summary>
Build log with Visual Studio 2019 generator
</summary>
<pre><code>C:\Users\rdeterre\Documents\hello-mfc\build-vs>cmake ..
-- Building for: Visual Studio 16 2019
-- The C compiler identification is MSVC 19.27.29111.0
-- The CXX compiler identification is MSVC 19.27.29111.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.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 (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/rdeterre/Documents/hello-mfc/build-vs
C:\Users\rdeterre\Documents\hello-mfc\build-vs>cmake --build .
Microsoft (R) Build Engine version 16.7.0+b89cb5fde for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.
Checking Build System
Building Custom Rule C:/Users/rdeterre/Documents/hello-mfc/CMakeLists.txt
hellomfc.cpp
_WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)
HelloMFC.vcxproj -> C:\Users\rdeterre\Documents\hello-mfc\build-vs\Debug\HelloMFC.exe
Building Custom Rule C:/Users/rdeterre/Documents/hello-mfc/CMakeLists.txt</code></pre>
</details>
But using the ninja generator fails with an "unresolved symbol _WinMain@16" error:
<details>
<summary>
Build log with Ninja generator
</summary>
<pre><code>C:\Users\rdeterre\Documents\hello-mfc\build-ninja>cmake .. -GNinja
-- The C compiler identification is MSVC 19.27.29111.0
-- The CXX compiler identification is MSVC 19.27.29111.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.27.29110/bin/Hostx86/x86/cl.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 (x86)/Microsoft Visual Studio/2019/Professional/VC/Tools/MSVC/14.27.29110/bin/Hostx86/x86/cl.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: C:/Users/rdeterre/Documents/hello-mfc/build-ninja
C:\Users\rdeterre\Documents\hello-mfc\build-ninja>cmake --build .
[1/2] Building CXX object CMakeFiles\HelloMFC.dir\hellomfc.cpp.obj
_WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)
[2/2] Linking CXX executable HelloMFC.exe
FAILED: HelloMFC.exe
cmd.exe /C "cd . && C:\Users\rdeterre\scoop\apps\cmake\3.18.1\bin\cmake.exe -E vs_link_exe --intdir=CMakeFiles\HelloMFC.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x86\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x86\mt.exe --manifests -- C:\PROGRA~2\MICROS~1\2019\PROFES~1\VC\Tools\MSVC\1427~1.291\bin\Hostx86\x86\link.exe /nologo CMakeFiles\HelloMFC.dir\hellomfc.cpp.obj /out:HelloMFC.exe /implib:HelloMFC.lib /pdb:HelloMFC.pdb /version:0.0 /machine:X86 /debug /INCREMENTAL /subsystem:windows kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
LINK Pass 1: command "C:\PROGRA~2\MICROS~1\2019\PROFES~1\VC\Tools\MSVC\1427~1.291\bin\Hostx86\x86\link.exe /nologo CMakeFiles\HelloMFC.dir\hellomfc.cpp.obj /out:HelloMFC.exe /implib:HelloMFC.lib /pdb:HelloMFC.pdb /version:0.0 /machine:X86 /debug /INCREMENTAL /subsystem:windows kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\HelloMFC.dir/intermediate.manifest CMakeFiles\HelloMFC.dir/manifest.res" failed (exit code 1120) with the following output:
msvcrtd.lib(exe_winmain.obj) : error LNK2019: unresolved external symbol _WinMain@16 referenced in function "int __cdecl invoke_main(void)" (?invoke_main@@YAHXZ)
HelloMFC.exe : fatal error LNK1120: 1 unresolved externals
ninja: build stopped: subcommand failed.
</code></pre></details>
Note that building works with both generators when taking out the `_UNICODE UNICODE` compile definitions.
In addition, adding `target_link_options(${PROJECT_NAME} PRIVATE "/entry:wWinMainCRTStartup")` to the CMakeLists.txt file solves the issue.https://gitlab.kitware.com/cmake/cmake/-/issues/21196pgfortran with nmake (VS2019 community version)2020-09-16T11:47:38-04:00ytzh15pgfortran with nmake (VS2019 community version)Hi, I'm trying to build a fortran library using pgfortran and get the following error,
```
The Fortran compiler identification is PGI 19.10.0
Detecting Fortran compiler ABI info
Detecting Fortran compiler ABI info - failed
Check for wor...Hi, I'm trying to build a fortran library using pgfortran and get the following error,
```
The Fortran compiler identification is PGI 19.10.0
Detecting Fortran compiler ABI info
Detecting Fortran compiler ABI info - failed
Check for working Fortran compiler: C:/Program Files/PGI/win64/19.10/bin/pgfortran.exe
Check for working Fortran compiler: C:/Program Files/PGI/win64/19.10/bin/pgfortran.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.18/Modules/CMakeTestFortranCompiler.cmake:51 (message):
The Fortran compiler
"C:/Program Files/PGI/win64/19.10/bin/pgfortran.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: C:/Users/me/Desktop/cmake-nmake-pgfortran/build-nmake/CMakeFiles/CMakeTmp
Run Build Command(s):nmake /nologo cmTC_63840\fast && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\HostX64\x64\nmake.exe" -f CMakeFiles\cmTC_63840.dir\build.make /nologo -L CMakeFiles\cmTC_63840.dir\build
Building Fortran object CMakeFiles/cmTC_63840.dir/testFortranCompiler.f.obj
C:\PROGRA~1\PGI\win64\19.10\bin\PGFORT~1.EXE -c C:\Users\me\Desktop\cmake-nmake-pgfortran\build-nmake\CMakeFiles\CMakeTmp\testFortranCompiler.f -o CMakeFiles\cmTC_63840.dir\testFortranCompiler.f.obj
Linking Fortran executable cmTC_63840.exe
C:\PROGRA~1\PGI\win64\19.10\bin\PGFORT~1.EXE @C:\Users\me\AppData\Local\Temp\nmBCBB.tmp
PGFORT~1-Error-Required tool link was not found
PGFORT~1... looked for link at C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.26.28801/bin/Hostx64/x64\link
PGFORT~1-Error-Tool loader was not found
NMAKE : fatal error U1077: 'C:\PROGRA~1\PGI\win64\19.10\bin\PGFORT~1.EXE' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\HostX64\x64\nmake.exe"' : return code '0x2'
Stop.
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:3 (enable_language)
Configuring incomplete, errors occurred!
See also "C:/Users/me/Desktop/cmake-nmake-pgfortran/build-nmake/CMakeFiles/CMakeOutput.log".
See also "C:/Users/me/Desktop/cmake-nmake-pgfortran/build-nmake/CMakeFiles/CMakeError.log".`
```
Note that it's looking for link.exe in the following folder,
`C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.26.28801/bin/Hostx64/x64\link`
But CMAKE_LINKER is set the correct value,
`C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.27.29110/bin/Hostx64/x64/link.exe`
The version # is different. Is this a bug with cmake or nmake ?https://gitlab.kitware.com/cmake/cmake/-/issues/21169clang-cl: No PDB generated for libraries with ClangCL on MSVC2020-09-18T06:33:43-04:00Mario Emmenlauerclang-cl: No PDB generated for libraries with ClangCL on MSVCI'm using cmake 3.18.1 with Visual Studio 2019 x64 and the clang-cl shipped with Visual Studio. Generally the build works quite well when setting `CC=clang-cl.exe` and `CXX=clang-cl.exe` after adding the clang-cl directory to `PATH`. I c...I'm using cmake 3.18.1 with Visual Studio 2019 x64 and the clang-cl shipped with Visual Studio. Generally the build works quite well when setting `CC=clang-cl.exe` and `CXX=clang-cl.exe` after adding the clang-cl directory to `PATH`. I can see that cmake detects also `lld-link.exe` for `CMAKE_LINKER`, and most of my builds "just work".
However I've just realized that no `PDB` files are generated for any libraries, not shared nor static ones. I'm using the following code to generate PDB's (that works on "classic" MSVC successfully):
```
if(TARGET_TYPE STREQUAL "SHARED_LIBRARY")
set_target_properties("${LIBRARYNAME}" PROPERTIES
PDB_NAME "${LIBRARYNAME}"
PDB_OUTPUT_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
elseif(TARGET_TYPE STREQUAL "STATIC_LIBRARY")
set_target_properties("${LIBRARYNAME}" PROPERTIES
COMPILE_PDB_NAME "${LIBRARYNAME}"
COMPILE_PDB_OUTPUT_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}")
endif()
```
Are PDB's for libraries already supported with clang-cl and cmake? Is there some way to enable them?
We try to preserve PDB debug information so we can later get back to debugging released binaries.https://gitlab.kitware.com/cmake/cmake/-/issues/21137CMAKE_LINKER incorrectly resolves to ld.lld with Clang on Windows2020-09-16T13:12:48-04:00Nick HutchinsonCMAKE_LINKER incorrectly resolves to ld.lld with Clang on WindowsWhen building with clang (not clang-cl) on Windows, CMAKE_LINKER is detected as ld.lld.exe, (the LLVM ELF linker) yet CMake actually performs linking using lld-link.exe (the LLVM COFF linker).
CMAKE_LINKER should be detected as the full...When building with clang (not clang-cl) on Windows, CMAKE_LINKER is detected as ld.lld.exe, (the LLVM ELF linker) yet CMake actually performs linking using lld-link.exe (the LLVM COFF linker).
CMAKE_LINKER should be detected as the full path to lld-link.exe in this instance.
**To reproduce:**
CMakeLists.txt
```
cmake_minimum_required(VERSION 3.18)
project(LinkerTest C)
message("CMAKE_C_CREATE_SHARED_LIBRARY=${CMAKE_C_CREATE_SHARED_LIBRARY}")
message("CMAKE_C_CREATE_SHARED_MODULE=${CMAKE_C_CREATE_SHARED_MODULE}")
message("CMAKE_C_LINK_EXECUTABLE=${CMAKE_C_LINK_EXECUTABLE}")
message("")
message("CMAKE_LINKER=${CMAKE_LINKER}")
```
Output:
```
# Assumes we're running in VS x64 command prompt.
$ cmake . -DCMAKE_C_COMPILER=clang -GNinja
...
CMAKE_C_CREATE_SHARED_LIBRARY=<CMAKE_C_COMPILER> -fuse-ld=lld-link -nostartfiles -nostdlib <CMAKE_SHARED_LIBRARY_C_FLAGS> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS> -o <TARGET> -Xlinker /implib:<TARGET_IMPLIB> -Xlinker /pdb:<TARGET_PDB> -Xlinker /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR> <OBJECTS> <LINK_LIBRARIES>
CMAKE_C_CREATE_SHARED_MODULE=<CMAKE_C_COMPILER> -fuse-ld=lld-link -nostartfiles -nostdlib <CMAKE_SHARED_LIBRARY_C_FLAGS> <LANGUAGE_COMPILE_FLAGS> <LINK_FLAGS> <CMAKE_SHARED_LIBRARY_CREATE_C_FLAGS> -o <TARGET> -Xlinker /implib:<TARGET_IMPLIB> -Xlinker /pdb:<TARGET_PDB> -Xlinker /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR> <OBJECTS> <LINK_LIBRARIES>
CMAKE_C_LINK_EXECUTABLE=<CMAKE_C_COMPILER> -fuse-ld=lld-link -nostartfiles -nostdlib <FLAGS> <CMAKE_C_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> -Xlinker /implib:<TARGET_IMPLIB> -Xlinker /pdb:<TARGET_PDB> -Xlinker /version:<TARGET_VERSION_MAJOR>.<TARGET_VERSION_MINOR> <LINK_LIBRARIES>
CMAKE_LINKER=C:/Program Files/LLVM/bin/ld.lld.exe
```https://gitlab.kitware.com/cmake/cmake/-/issues/21111CMake Windows Installer Needlessly Wants Admin Privileges2020-08-20T11:51:09-04:00Frank IannarilliCMake Windows Installer Needlessly Wants Admin PrivilegesThe .msi installer prompts non-privileged user for Admin password even when user selects option to "set path only for current user". I realize one can do a non-Admin install using the .ZIP distribution, but this behavior of the .msi wil...The .msi installer prompts non-privileged user for Admin password even when user selects option to "set path only for current user". I realize one can do a non-Admin install using the .ZIP distribution, but this behavior of the .msi will throw up a roadblock for some users.https://gitlab.kitware.com/cmake/cmake/-/issues/21022Ninja: Backslashes on Windows incompatible with Embedded-GCC-compiler, can't ...2021-03-28T06:43:47-04:00Ta KraNinja: Backslashes on Windows incompatible with Embedded-GCC-compiler, can't reformat to forwardslashI have to use a certain kind of compiler (Hightec tricore GCC) for this project.
I'm building on Windows 10 with Cmake 3.17.2(0032601-MSVC_2) and Ninja 1.10.0.
There's a bug in the compiler's handling of response-files where it does not...I have to use a certain kind of compiler (Hightec tricore GCC) for this project.
I'm building on Windows 10 with Cmake 3.17.2(0032601-MSVC_2) and Ninja 1.10.0.
There's a bug in the compiler's handling of response-files where it does not escape \ in paths properly.
`-I..\..\platforms\win_tricore-gcc\include`
ends up as:
`ignoring nonexistent directory "....platformswin_tricore-gccinclude"`
(only when using response files, standard command line works)
There are 2 things I tried to work around the bug:
1. disable response files -> for some reason CMake ignores my `CMAKE_C_USE_RESPONSE_FILE_FOR_OBJECTS `and `CMAKE_NINJA_FORCE_RESPONSE_FILE `being set to 0 when using ninja, it just always uses response files. (only recently, not sure what changed)
2. replace \ with / in paths that are passed as parameters (through response file) -> for compile options that can be done with REGEX REPLACE, but no idea how to do that with include-paths as they are dynamically generated by CMake.
Is there any way to switch from `\` to `/` on windows?
Is there any mechanism to edit response files before use?https://gitlab.kitware.com/cmake/cmake/-/issues/20999FindOpenMP: unable to detect OpenMP on windows with MSVC+Clang2020-07-22T07:11:41-04:00Yue JINFindOpenMP: unable to detect OpenMP on windows with MSVC+ClangThe version of CMake is 3.18.0
- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.19041.
- The C compiler identification is Clang 10.0.0 with MSVC-like command-line
- The CXX compiler identification is Clang 10.0.0 ...The version of CMake is 3.18.0
- Selecting Windows SDK version 10.0.18362.0 to target Windows 10.0.19041.
- The C compiler identification is Clang 10.0.0 with MSVC-like command-line
- The CXX compiler identification is Clang 10.0.0 with MSVC-like command-line
- Detecting C compiler ABI info
- Detecting C compiler ABI info - done
- Check for working C compiler: C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/Llvm/bin/clang-cl.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 (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/Llvm/bin/clang-cl.exe -- skipped
- Detecting CXX compile features
- Detecting CXX compile features - done
- Found HDF5: D:/Program Files/HDF_Group/HDF5/1.12.0/lib/hdf5.lib (found version "1.12.0") found components: C HL
- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES)
- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES)
- Could NOT find OpenMP (missing: OpenMP_C_FOUND OpenMP_CXX_FOUND)https://gitlab.kitware.com/cmake/cmake/-/issues/20994Windows: "file COPY cannot read symlink" when using data deduplication (Windo...2021-04-04T08:16:15-04:00Johannes Mueller-RoemerWindows: "file COPY cannot read symlink" when using data deduplication (Windows/NTFS)When data deduplication is enabled on a Windows machine, CMake commands like `file(COPY...)` fail with a "cannot read symlink" error when trying to copy a deduplicated file. See also https://github.com/Microsoft/vcpkg/issues/2488When data deduplication is enabled on a Windows machine, CMake commands like `file(COPY...)` fail with a "cannot read symlink" error when trying to copy a deduplicated file. See also https://github.com/Microsoft/vcpkg/issues/2488https://gitlab.kitware.com/cmake/cmake/-/issues/20929Clang-cl cross compilation assembler for windows ARM642020-07-14T07:25:41-04:00Evgeny FimochkinClang-cl cross compilation assembler for windows ARM64I use clang-cl for cross compilation C++/C, ASM for windows ARM64.
There are 2 problems:
- Ninja generator create rule clang-cl for ASM files which is wrong, and should use clang.exe for compilation .s files, can be fixed by patching Pla...I use clang-cl for cross compilation C++/C, ASM for windows ARM64.
There are 2 problems:
- Ninja generator create rule clang-cl for ASM files which is wrong, and should use clang.exe for compilation .s files, can be fixed by patching Platform\Windows-Clang.cmake and Platform\Windows-Clang-ASM.cmake, can write MR for this
- Visual Studio 2019 generator doesn`t create rules for asm files
Questions:
- Is it ok to create on windows rule for clang.exe when user uses clang-cl?
- Should I create patch for VS 2019 generator?
- Or this problem can be solved other way?https://gitlab.kitware.com/cmake/cmake/-/issues/20904InstallRequiredSystemLibraries, Intel Fortran2020-07-02T12:40:01-04:00Torgeir RustenInstallRequiredSystemLibraries, Intel FortranIn i Fortran project I use the InstallRequiredSystemLibraries module. I use the Intel Fortran Compiler:
```
c:\NinjaCmake\Fortran>cmake -B CMakeBuild -G "Ninja"
-- The Fortran compiler identification is Intel 19.1.0.20200306
....
...In i Fortran project I use the InstallRequiredSystemLibraries module. I use the Intel Fortran Compiler:
```
c:\NinjaCmake\Fortran>cmake -B CMakeBuild -G "Ninja"
-- The Fortran compiler identification is Intel 19.1.0.20200306
....
```
The InstallRequiredSystemLibraries issue the message:
```
CMake Warning at C:/Program Files/CMake/share/cmake-3.18/Modules/InstallRequiredSystemLibraries.cmake:699 (message):
system runtime library file does not exist: 'C:/Program Files
(x86)/IntelSWTools/compilers_and_libraries_2020.1.216/windows/redist/intel64/compiler/libioffload_host.dll'
Call Stack (most recent call first):
CMakeLists.txt:17 (include)
```
This library, and also the liboffload.dll and libmpx.lib, are removed from the Intel redist.
In my CMakeLists.txt I have an install command and when I install the Release version of my program the following dll's are installed:
```
-- Installing: C:/NinjaCmake/Fortran/./bin/msvcp140.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/vcruntime140.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/concrt140.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/cilkrts20.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libchkp.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libirngmd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libmmd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libmmdd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/svml_dispmd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/ifdlg100.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libicaf.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libifcoremd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libifcoremdd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libifcorert.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libifcorertd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libifportmd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1033
-- Installing: C:/NinjaCmake/Fortran/./bin/1033/ifcore_msg.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1033/irc_msg.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1033/libmUI.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1041
-- Installing: C:/NinjaCmake/Fortran/./bin/1041/ifcore_msg.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1041/irc_msg.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1041/libiomp5ui.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1041/libmUI.dll
```
Here libmmdd.dll, libifcoremdd.dll are debug dll's and could be removed from the installation.
Furthermore, I think msvcp140, concrt140 and cilkrts20 are c++ libraries and could be removed? I have never shipped them with Fortran executables. From the intel documentation it also look like libirngmd is also for c++.
The libifcorert is used when compiling using /MDs (single threaded dynamic library) , as far as I understand from the Intel documentation the /MDs switch is depreciated so I guess the libifcorert.dll could also be removed.
My guess is that libchkp(check pointers), ifdlg100(interface dialog) and libicaf(co arrays) are not much used and can also be removed.https://gitlab.kitware.com/cmake/cmake/-/issues/20881IPO: Intel C++ for Windows2022-03-30T15:41:22-04:00Matheus IzvekovIPO: Intel C++ for WindowsTested on Intel C++ compiler 19.1 with VS 2019
check_ipo_supported fails: CMake doesn't support IPO for current CXX compiler
My own analysis:
Looking at the code, it is only supported for linux in `Compiler\Intel.cmake`.
From the oth...Tested on Intel C++ compiler 19.1 with VS 2019
check_ipo_supported fails: CMake doesn't support IPO for current CXX compiler
My own analysis:
Looking at the code, it is only supported for linux in `Compiler\Intel.cmake`.
From the other side, `Platform\Windows-MSVC.cmake` does not handle `Intel` Compiler ID.https://gitlab.kitware.com/cmake/cmake/-/issues/20805Visibility on object libraries inconsistent across platforms2022-04-06T13:50:22-04:00Daniel WyattVisibility on object libraries inconsistent across platformsSee [this example](https://github.com/CarloWood/cmaketest).
On Linux-GNU, the DSO will *not* export `bar_func_hidden()`.
On Windows-GNU, the DLL *will* export `bar_func_hidden()` (and others). This is with MSYS2's cmake 3.17.3 and g++ ...See [this example](https://github.com/CarloWood/cmaketest).
On Linux-GNU, the DSO will *not* export `bar_func_hidden()`.
On Windows-GNU, the DLL *will* export `bar_func_hidden()` (and others). This is with MSYS2's cmake 3.17.3 and g++ 10.1.0.
I was thinking this maybe stems from the use of `whole-archive` [here](https://gitlab.kitware.com/cmake/cmake/-/blob/624a13046f1ee6ef123155514bafb7c9bc284220/Modules/Platform/Windows-GNU.cmake#L120).https://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/20705Clang + MinGW fails because it uses msvc-style lld-link2020-07-14T01:22:42-04:00Trass3rClang + MinGW fails because it uses msvc-style lld-linkSetup:
* QtCreator installed along with mingw730_64/mingw810_64 and Qt 5.14.2\mingw73_64
* System CMake is 3.17.1 and LLVM 10 release installed in C:\Program Files\LLVM\bin
The project builds fine with MinGW but fails when trying to ...Setup:
* QtCreator installed along with mingw730_64/mingw810_64 and Qt 5.14.2\mingw73_64
* System CMake is 3.17.1 and LLVM 10 release installed in C:\Program Files\LLVM\bin
The project builds fine with MinGW but fails when trying to build with clang instead.
QtCreator creates a reasonable qtcsettings.cmake:
```cmake
set("CMAKE_BUILD_TYPE" "Debug" CACHE "STRING" "" FORCE)
set("CMAKE_CXX_COMPILER" "C:/Program Files/LLVM/bin/clang++.exe" CACHE "STRING" "" FORCE)
set("CMAKE_CXX_COMPILER_TARGET " "x86_64-w64-mingw32" CACHE "STRING" "" FORCE)
set("CMAKE_C_COMPILER" "C:/Program Files/LLVM/bin/clang.exe" CACHE "STRING" "" FORCE)
set("CMAKE_C_COMPILER_TARGET" "x86_64-w64-mingw32" CACHE "STRING" "" FORCE)
set("CMAKE_PREFIX_PATH" "C:/Qt/5.14.2/mingw73_64" CACHE "STRING" "" FORCE)
set("CMAKE_SYSROOT" "C:/Qt/Tools/mingw810_64" CACHE "STRING" "" FORCE)
set("QT_QMAKE_EXECUTABLE" "C:/Qt/5.14.2/mingw73_64/bin/qmake.exe" CACHE "STRING" "" FORCE)
```
```
Running C:\Program Files\CMake\bin\cmake.exe "-GCodeBlocks - Ninja" -C %Temp%\QtCreator-RclHbn\qtc-cmake-hAWJYpeC\qtcsettings.cmake %projectdir% in %Temp%\QtCreator-RclHbn\qtc-cmake-hAWJYpeC.
loading initial cache file %Temp%\QtCreator-RclHbn\qtc-cmake-hAWJYpeC\qtcsettings.cmake
-- The C compiler identification is Clang 10.0.0 with GNU-like command-line
-- The CXX compiler identification is Clang 10.0.0 with GNU-like command-line
-- Check for working C compiler: C:/Program Files/LLVM/bin/clang.exe
-- Check for working C compiler: C:/Program Files/LLVM/bin/clang.exe - broken
CMake Error at C:/Program Files/CMake/share/cmake-3.17/Modules/CMakeTestCCompiler.cmake:60 (message):
The C compiler
"C:/Program Files/LLVM/bin/clang.exe"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: %Temp%/QtCreator-RclHbn/qtc-cmake-hAWJYpeC/CMakeFiles/CMakeTmp
Run Build Command(s):C:/Tools/ninja.exe cmTC_886e9 && [1/2] 0.062s Building C object CMakeFiles/cmTC_886e9.dir/testCCompiler.c.obj
[2/2] 0.388s Linking C executable cmTC_886e9.exe
FAILED: cmTC_886e9.exe
cmd.exe /C "cd . && C:\PROGRA~1\LLVM\bin\clang.exe -fuse-ld=lld-link -nostartfiles -nostdlib -g -Xclang -gcodeview -O0 -D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd CMakeFiles/cmTC_886e9.dir/testCCompiler.c.obj -o cmTC_886e9.exe -Xlinker /implib:cmTC_886e9.lib -Xlinker /pdb:cmTC_886e9.pdb -Xlinker /version:0.0 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -loldnames && cd ."
lld-link: error: could not open 'kernel32.lib': no such file or directory
lld-link: error: could not open 'user32.lib': no such file or directory
lld-link: error: could not open 'gdi32.lib': no such file or directory
lld-link: error: could not open 'winspool.lib': no such file or directory
lld-link: error: could not open 'shell32.lib': no such file or directory
lld-link: error: could not open 'ole32.lib': no such file or directory
lld-link: error: could not open 'oleaut32.lib': no such file or directory
lld-link: error: could not open 'uuid.lib': no such file or directory
lld-link: error: could not open 'comdlg32.lib': no such file or directory
lld-link: error: could not open 'advapi32.lib': no such file or directory
lld-link: error: could not open 'oldnames.lib': no such file or directory
lld-link: error: could not open 'msvcrtd.lib': no such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
```
Of course it can't find kernel32.lib cause MinGW has libkernel32.a etc.https://gitlab.kitware.com/cmake/cmake/-/issues/20404Ninja: Broken build.ninja when build tree is a Windows drive root2020-03-03T06:56:59-05:00Andrei JianuNinja: Broken build.ninja when build tree is a Windows drive rootHi all,
**Description**:
In case of generating the ninja build solution in the root directory of any disk, CMake is adding a `$` before `:` or ` ` (space)[CMakeNinjaVS.zip](/uploads/fa9bfb4486c601eaad7dc279b278a934/CMakeNinjaVS.zip).
...Hi all,
**Description**:
In case of generating the ninja build solution in the root directory of any disk, CMake is adding a `$` before `:` or ` ` (space)[CMakeNinjaVS.zip](/uploads/fa9bfb4486c601eaad7dc279b278a934/CMakeNinjaVS.zip).
**Ninja build exmaple**
```
...
#############################################
# Make the all target the default.
default all
#############################################
# Re-run CMake if any of its inputs changed.
build build.ninja: RERUN_CMAKE | C$:\Program$ Files\3rdPartyApps\cmake\share\cmake-3.16\Modules\CMakeCCompiler.cmake.in C$:\Program$ Files\3rdPartyApps\cmake\share\cmake-3.16\Modules\CMakeCCompilerABI.c ...
#############################################
# A missing CMake input file is not an error.
build C$:\Program$ Files\3rdPartyApps\cmake\share\cmake-3.16\Modules\CMakeCCompiler.cmake.in C$:\Program$ Files\3rdPartyApps\cmake\share\cmake-3.16\Modules\CMakeCCompilerABI.c C$:\Program$ Files\3rdPartyApps\cmake\share\cmake-3.16\Modules\CMakeCInformation.cmake ...
...
```
**Environment**
CMake: 3.16.4
Ninja: 1.10.0
Windows: Windows 10 Pro 1909 (OS build: 18363.693)
**How to reproduce**
Attached you have an zip with a small test project that creates a virtual drive, W:, and generate the ninja project and tries to build it.
It uses Visual Studio for it and it is necessary to have vswhere.exe in your environment path as is using to find the Visual Studio installation path.
PS: This has been reported to ninja issue board also
https://github.com/ninja-build/ninja/issues/1747