CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2021-04-25T11:02:51-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/21914IPO support check fails if CUDA is specified before CXX in enabled languages ...2021-04-25T11:02:51-04:00Pasquale ColaianniIPO support check fails if CUDA is specified before CXX in enabled languages (on Windows, with Clang)[test_ipo_windows_clang_cuda_cxx.zip](/uploads/fe037376eb21c8aa6cb000d5f5f14ac9/test_ipo_windows_clang_cuda_cxx.zip)
- Platform: Windows
- Compiler: clang++ or clang-cl
- Generator: Ninja
In a project with CUDA enabled, specifying CUDA...[test_ipo_windows_clang_cuda_cxx.zip](/uploads/fe037376eb21c8aa6cb000d5f5f14ac9/test_ipo_windows_clang_cuda_cxx.zip)
- Platform: Windows
- Compiler: clang++ or clang-cl
- Generator: Ninja
In a project with CUDA enabled, specifying CUDA before CXX breaks the cache generation.
The attachment serves as an example project.
```cmake
cmake_minimum_required(VERSION 3.18)
# Platform: Windows
# Command: cmake -G Ninja -D CMAKE_CXX_COMPILER="clang++" <src path>
# It fails also with clang-cl
# It does not fail with MSVC
# project(TestProgram LANGUAGES CXX CUDA) # this works
project(TestProgram LANGUAGES CUDA CXX) # this does not
include(CheckIPOSupported)
check_ipo_supported(RESULT result OUTPUT output LANGUAGES CXX)
if(result)
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION TRUE)
message(STATUS "Interprocedural Optimization is ON for CXX")
else()
message(SEND_ERROR "IPO is not supported: ${output}")
endif()
add_library(lib STATIC lib.cpp)
add_executable(test_program main.cpp)
target_link_libraries(test_program PRIVATE lib)
```
<details><summary>_CMakeError.log_</summary>
```
CXX compiler IPO check failed with the following output:
Change Dir: D:/test_ipo_windows_clang_cuda_cxx/build/CMakeFiles/_CMakeLTOTest-CXX/bin
Run Build Command(s):D:/PROGRA~1/Ninja/ninja.exe && [1/4] Building CXX object CMakeFiles\foo.dir\foo.cpp.obj
[2/4] Building CXX object CMakeFiles\boo.dir\main.cpp.obj
[3/4] Linking CXX static library foo.lib
FAILED: foo.lib
cmd.exe /C "cd . && D:\PROGRA~1\MICROS~2\2019\BUILDT~1\VC\Tools\MSVC\1428~1.293\bin\Hostx64\x64\lib.exe /machine:x64 /out:foo.lib CMakeFiles\foo.dir\foo.cpp.obj && cd ."
Microsoft (R) Library Manager Version 14.28.29336.0
Copyright (C) Microsoft Corporation. All rights reserved.
CMakeFiles\foo.dir\foo.cpp.obj : fatal error LNK1107: invalid or corrupt file: cannot read at 0xBEC
ninja: build stopped: subcommand failed.
```
</details>https://gitlab.kitware.com/cmake/cmake/-/issues/21816Ninja: Debug symbols in Fortran with Intel compiler on Windows2022-02-23T08:48:20-05:00Andreas SchulzNinja: Debug symbols in Fortran with Intel compiler on Windows**Description**
There is a problem with debugging Fortran code, because the source code reference in the object file is not set correctly.
**Reproducer**
[reproducer.zip](/uploads/e7d1e27a360e51f7027f0c68ff074e87/reproducer.zip)
**Addi...**Description**
There is a problem with debugging Fortran code, because the source code reference in the object file is not set correctly.
**Reproducer**
[reproducer.zip](/uploads/e7d1e27a360e51f7027f0c68ff074e87/reproducer.zip)
**Additional Information**
Apparently, during preprocessing of a source file with the Intel compiler the result is written to the terminal and then redirected into a subfolder. This behavior is defined in
CMAKE_Fortran_PREPROCESS_SOURCE (more precisely, here: -E > <PREPROCESSED_SOURCE>).
The preprocessed file contains a reference to the source file in the first line comment
(# 1 “…\main.f” in the minimal example),
which is used by the Intel compiler to create the reference in the object file. But since the preprocessed file is shifted into a subfolder, the relative path becomes outdated and in the object file we get an invalid path
(CMakeFiles\hello_world_fortran.dir…\main.f in the minimal example).
**Version Information**
The problem appears with Ninja version 1.9.0, CMake version 3.19.3, IFort version 19.1.1.216, and Fortran 77.https://gitlab.kitware.com/cmake/cmake/-/issues/21809SameFile() slows down install actions on Windows2021-02-15T11:26:44-05:00jalfdSameFile() slows down install actions on Windowsin `cmFileCopier::Install`, `SameFile()` is called as part of the up-to-date checks to determine if actually copying the file is necessary. The purpose of this seems to be an optimization, to avoid unnecessary file copies.
However, on W...in `cmFileCopier::Install`, `SameFile()` is called as part of the up-to-date checks to determine if actually copying the file is necessary. The purpose of this seems to be an optimization, to avoid unnecessary file copies.
However, on Windows, the `SameFile()` function is actually quite expensive, as it has to open both files with calls to `CreateFileW`.
Additionally, it is my understanding that the file will in practice always return false, as CMake would have to create a hard link during the install action for it to return true, and at least on Windows, it never does this.
Therefore, I would suggest that `cmFileCopier::Install` should only call `SameFile` on non-Windows platforms, where encountering hard links in the first place is actually feasible, and where checking whether the files are the same is much cheaper (just a `stat()` call, rather than having to open the files).
In my testing, I'm seeing a speedup for installs of around 30% just from removing this one call to `SameFile()`.https://gitlab.kitware.com/cmake/cmake/-/issues/21657RFE: provide regexes to ignore "magic" DLLs on Windows/system libraries on macOS2021-01-04T10:29:55-05:00Ben BoeckelRFE: provide regexes to ignore "magic" DLLs on Windows/system libraries on macOSOn Windows, there are DLL entries for "API sets" which are Microsoft's method for ABI compatibility in the future. We should provide a module which contains lists of these regexes.
On macOS, `libSystem.dylib` should never be packaged, s...On Windows, there are DLL entries for "API sets" which are Microsoft's method for ABI compatibility in the future. We should provide a module which contains lists of these regexes.
On macOS, `libSystem.dylib` should never be packaged, so exclusions for that platform also make sense to provide.
See [this Discourse comment](https://discourse.cmake.org/t/get-runtime-dependencies-has-difficulties-with-windows-api-sets/1768/7).
Cc: @kyle.edwards @ben.boeckelhttps://gitlab.kitware.com/cmake/cmake/-/issues/21638Generating import libraries without .dll, only through .def2023-03-29T03:09:38-04:00Clément GrégoireGenerating import libraries without .dll, only through .defI am trying to generate an import library for an external DLL that does not have one.
This means that I do not have the sources but only the `.def` file.
Is there a way to create an import library only in CMake ?
The linker command onl...I am trying to generate an import library for an external DLL that does not have one.
This means that I do not have the sources but only the `.def` file.
Is there a way to create an import library only in CMake ?
The linker command only needs to use `/DEF:` without any other inputs to work:
`lib /DEF:somelib.def /Out:somelib.lib /machine:x86`
I tried a few things but none seems to work:
- `SHARED` with no source file other than the `.def` will not invoke the linker, and thus not generate any `.lib` nor `.dll`
- `SHARED` with an empty `.cpp` source file will try to generate both `.lib` and `.dll`, which fails since symbols referenced by the `.def` do not exist
- `STATIC` with no source file other than the `.def` will not invoke the linker, and thus not generate any `.lib`
- `STATIC` with an empty `.cpp` source file will not invoke the linker, and thus not generate a `.lib` but the `.def` will not be used
I also tried setting `STATIC_LIBRARY_OPTIONS` (see below), but if you provide `.obj` files to the linker, it will not work as it will try to find functions referenced in the .def as if we were generating a `.dll`. And since the linker is not invoked without any `.cpp` file in the source list, well, I'm stuck.
```
set_target_properties(Fog PROPERTIES
LINKER_LANGUAGE CXX
STATIC_LIBRARY_OPTIONS "/DEF:${CMAKE_CURRENT_LIST_DIR}/definitions/Fog.${D2MOO_ORDINALS_VERSION}.def"
)
```
Is using a custom target + and `IMPORTED` cmake library the only thing I can use for this ?
Am I missing something ? I know it's pretty unusual to create an import library without also creating a .dll, is that something CMake should support out of the box ?https://gitlab.kitware.com/cmake/cmake/-/issues/21635CheckIPOSupported: Never detects LTO/IPO for Clang on Windows2021-01-10T15:55:25-05:00Sztergbaum RomanCheckIPOSupported: Never detects LTO/IPO for Clang on WindowsHello i'm trying the following code in my CMake:
```CMake
if (CMAKE_BUILD_TYPE STREQUAL "Release")
include(CheckIPOSupported)
check_ipo_supported(RESULT ipo_supported OUTPUT output)
if (ipo_supported)
set(CMAKE_INTER...Hello i'm trying the following code in my CMake:
```CMake
if (CMAKE_BUILD_TYPE STREQUAL "Release")
include(CheckIPOSupported)
check_ipo_supported(RESULT ipo_supported OUTPUT output)
if (ipo_supported)
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON)
message(STATUS "We are in release - Successfully enabled IPO")
else ()
message(WARNING "IPO NOT SUPPORTED - Skipping reason: ${output}")
endif ()
endif ()
```
And i always get:
```
CMake Warning at CMakeLists.txt:63 (message):
IPO NOT SUPPORTED - Skipping reason: Change Dir:
C:/Users/Public/Documents/atomicDEX-Desktop/cmake-build-release/CMakeFiles/_CMakeLTOTest-CXX/bin
Run Build Command(s):C:/ProgramData/scoop/shims/ninja.exe && [1/4] Building
CXX object CMakeFiles/foo.dir/foo.cpp.obj
[2/4] Building CXX object CMakeFiles/boo.dir/main.cpp.obj
[3/4] Linking CXX static library foo.lib
[4/4] Linking CXX executable boo.exe
FAILED: boo.exe
cmd.exe /C "cd . && C:\ProgramData\scoop\shims\clang++.exe
-fuse-ld=lld-link -nostartfiles -nostdlib -g -Xclang -gcodeview -O0
-D_DEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrtd -flto
CMakeFiles/boo.dir/main.cpp.obj -o boo.exe -Xlinker /implib:boo.lib
-Xlinker /pdb:boo.pdb -Xlinker /version:0.0 foo.lib -lkernel32 -luser32
-lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32
-ladvapi32 -loldnames && cmd.exe /C "cd /D
C:\Users\Public\Documents\atomicDEX-Desktop\cmake-build-release\CMakeFiles\_CMakeLTOTest-CXX\bin
&& C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noprofile
-executionpolicy Bypass -file
C:/Users/Public/Documents/atomicDEX-Desktop/ci_tools_atomic_dex/vcpkg-repo/scripts/buildsystems/msbuild/applocal.ps1
-targetBinary
C:/Users/Public/Documents/atomicDEX-Desktop/cmake-build-release/CMakeFiles/_CMakeLTOTest-CXX/bin/boo.exe
-installedDir
C:/Users/Public/Documents/atomicDEX-Desktop/ci_tools_atomic_dex/vcpkg-repo/installed/x64-windows/debug/bin
-OutVariable out""
lld-link: error: undefined symbol: int __cdecl foo(void)
>>> referenced by
C:/Users/Public/Documents/atomicDEX-Desktop/cmake-build-release/CMakeFiles/_CMakeLTOTest-CXX/src/main.cpp
>>> CMakeFiles/boo.dir/main.cpp.obj
clang++: error: linker command failed with exit code 1 (use -v to see
invocation)
ninja: build stopped: subcommand failed.
```
Is there any reason ?
Compiler infos:
```
PS C:\Users\Public\Documents\atomicDEX-Desktop> clang --version
clang version 11.0.0
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\ProgramData\scoop\apps\llvm\current\bin
```
CMake version: 3.19.2
full CMake to reproduce:
```CMake
cmake_minimum_required(VERSION 3.19.2)
project(cmake_lto)
set(CMAKE_CXX_STANDARD 20)
if (CMAKE_BUILD_TYPE STREQUAL "Release")
include(CheckIPOSupported)
check_ipo_supported(RESULT ipo_supported OUTPUT output)
if (ipo_supported)
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION ON)
message(STATUS "We are in release - Successfully enabled IPO")
else ()
message(WARNING "IPO NOT SUPPORTED - Skipping reason: ${output}")
endif ()
endif ()
add_executable(cmake_lto main.cpp)
```
Note: -flto=thin is not used even if it's available: https://clang.llvm.org/docs/ThinLTO.html
Usage on windows:
```
clang-cl -flto=thin -O2 -c file1.c file2.c
% lld-link /out:a.exe file1.obj file2.obj
```https://gitlab.kitware.com/cmake/cmake/-/issues/21536Pelles C toolchain support2020-12-01T12:39:59-05:00Charlie LinPelles C toolchain supportHas anyone added support for the toolchain here: http://www.smorgasbordet.com/pellesc/?
It claims full support for C99, C11, and C17, of which MSVC does not fully support these C versions.Has anyone added support for the toolchain here: http://www.smorgasbordet.com/pellesc/?
It claims full support for C99, C11, and C17, of which MSVC does not fully support these C versions.https://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/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.