CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-10-28T18:01:00-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/22355CMake 3.21.0-rc unable to establish a SSL connection on Windows2022-10-28T18:01:00-04:00Peter WaleckiCMake 3.21.0-rc unable to establish a SSL connection on WindowsCMake 3.21.0-rc is unable to open SSH connections to download dependencies when configuring Open3D on Windows 10. Downgrading to 3.19.0 resolves the issue.
cmake produces the following error:
```
Performing download step (download, ver...CMake 3.21.0-rc is unable to open SSH connections to download dependencies when configuring Open3D on Windows 10. Downgrading to 3.19.0 resolves the issue.
cmake produces the following error:
```
Performing download step (download, verify and extract) for 'ext_turbojpeg'
-- verifying file...
file='D:/Documents/Brown/Open3D/3rdparty_downloads/libjpeg-turbo/2.0.6.tar.gz'
-- SHA256 hash of
D:/Documents/Brown/Open3D/3rdparty_downloads/libjpeg-turbo/2.0.6.tar.gz
does not match expected value
expected: '005aee2fcdca252cee42271f7f90574dda64ca6505d9f8b86ae61abc2b426371'
actual: 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855'
-- File already exists but hash mismatch. Removing...
-- Downloading...
dst='D:/Documents/Brown/Open3D/3rdparty_downloads/libjpeg-turbo/2.0.6.tar.gz'
timeout='none'
inactivity timeout='none'
-- Using src='https://github.com/libjpeg-turbo/libjpeg-turbo/archive/refs/tags/2.0.6.tar.gz'
CMake Error at ext_turbojpeg-stamp/download-ext_turbojpeg.cmake:170 (message):
Each download failed!
CUSTOMBUILD : error : downloading 'https://github.com/libjpeg-turbo/libjpeg-turbo/archive/refs/tags/2.0.6.tar.gz' faile
d [D:\Documents\Brown\Open3D\build\ext_turbojpeg.vcxproj]
status_code: 35
status_string: "SSL connect error"
log:
--- LOG BEGIN ---
timeout on name lookup is not supported
Trying 140.82.112.4:443...
Connected to github.com (140.82.112.4) port 443 (#0)
schannel: disabled automatic use of client certificate
schannel: ALPN, offering h2
schannel: ALPN, offering http/1.1
schannel: initial InitializeSecurityContext failed: SEC_E_ILLEGAL_MESSAGE
(0x80090326) - This error usually occurs when a fatal SSL/TLS alert is
received (e.g. handshake failed). More detail may be available in the
Windows System event log.
Closing connection 0
--- LOG END ---
```
Steps to reproduce.
1. clone Open3D from https://github.com/intel-isl/Open3D.git (commit hash 09aa226f993180bf2ab7e8884e740db6e9c219bd)
2. Open cmd with Admin priviledges
3. cd Open3D
4. mkdir build
5. cd build
6. cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_INSTALL_PREFIX="../install" -DBUILD_PYTHON_MODULE=OFF ..3.21.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22444cmake 3.21.0 output mixes LF and CRLF newlines2021-11-06T13:27:41-04:00Brad Kingcmake 3.21.0 output mixes LF and CRLF newlinesOn Windows, create a `msg.cmake` script containing:
```cmake
message("one\ntwo")
```
Run it as `cmake -P msg.cmake`.
With CMake 3.20 and lower, the output on `stderr` is `one\ntwo\n`. With CMake 3.21.0, the output on `stderr` is `one...On Windows, create a `msg.cmake` script containing:
```cmake
message("one\ntwo")
```
Run it as `cmake -P msg.cmake`.
With CMake 3.20 and lower, the output on `stderr` is `one\ntwo\n`. With CMake 3.21.0, the output on `stderr` is `one\r\ntwo\n`.3.21.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22429ParaView fails to link its xdmf2 module under CMake 3.21.02021-07-15T20:47:03-04:00Ben BoeckelParaView fails to link its xdmf2 module under CMake 3.21.0Under investigation. We have [a passing build](https://open.cdash.org/build/7341894) and [a failing build](https://open.cdash.org/build/7342157). Investigating the difference now; will likely bisect CMake at some point.
Working combinat...Under investigation. We have [a passing build](https://open.cdash.org/build/7341894) and [a failing build](https://open.cdash.org/build/7342157). Investigating the difference now; will likely bisect CMake at some point.
Working combination: paraview/paraview@ce2f8fbd2db3e7342b1f4e3f62067a991da9ab21 paraview/paraview-superbuild@7844778544a78b29d735201aae17ecdaa91dbf1d
Not working combination: paraview/paraview@4181a76ad20b696bd79aa017a7ad6209c6981d2c paraview/paraview-superbuild@8b74a338bfdacbafdc1c32602cfef70a88604ae23.21.1https://gitlab.kitware.com/cmake/cmake/-/issues/22388IntelLLVM: on Windows, does not respect CXX_STANDARD2021-09-20T11:42:51-04:00scivisionIntelLLVM: on Windows, does not respect CXX_STANDARDOn Windows with Intel LLVM oneAPI 2021.3 "icx" C++ compiler, CMake 3.20/3.21 doesn't emit the required "/std:c++17" or similar flag.
This does work as expected on MacOS and Linux with "icpx".
So it could be something internal to CMake w...On Windows with Intel LLVM oneAPI 2021.3 "icx" C++ compiler, CMake 3.20/3.21 doesn't emit the required "/std:c++17" or similar flag.
This does work as expected on MacOS and Linux with "icpx".
So it could be something internal to CMake where "icx" isn't getting the "/std:c++17" like flag.
Reproduce with this CMakeLists.txt. This example is chosen as one that fails on many current compilers without the `/std` flag.
```cmake
cmake_minimum_required(VERSION 3.20)
project(test LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANARD_REQUIRED true)
include(CheckSourceCompiles)
check_source_compiles(CXX
"#include <filesystem>
int main() {
std::filesystem::path p;
return EXIT_SUCCESS;}"
HAVE_CXX_FILESYSTEM
)
```
The incorrect result here is that HAVE_CXX_FILESYSTEM is false.
if I add `set(CMAKE_REQUIRED_FLAGS /std:c++17)` then HAVE_CXX_FILESYSTEM is true as expected. The actual feature or C++ standard (17, 20, etc.) doesn't seem to matter--IntelLLVM on Windows does not add the `/std:` flag added from CMake.
This failure is also true for a simple target like:
```cmake
add_executable(hello hello.cxx)
target_compile_features(hello PRIVATE cxx_std_17)
```
The Intel classic "icl" on Windows does work as expected.3.20.6Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22764cmake.exe --install does not write "cmake_mode_t" ADS when cross compiling2021-10-18T09:29:24-04:00georg-emgcmake.exe --install does not write "cmake_mode_t" ADS when cross compilingWhen using CMake version from the 64-Bit Windows installer for CMake 3.21.3, the installed cmake somehow no longer writes the "cmake_mode_t" alternate NTFS data stream that CPackDeb needs to set the permissions correctly. Oddly, if I bui...When using CMake version from the 64-Bit Windows installer for CMake 3.21.3, the installed cmake somehow no longer writes the "cmake_mode_t" alternate NTFS data stream that CPackDeb needs to set the permissions correctly. Oddly, if I build the identical version of CMake myself, it works ok.
I have attached a test project to demonstrate what I mean.
[CMake-permissions.zip](/uploads/eafb695c0335517e88edcfa5e3be56f7/CMake-permissions.zip)
Running the `test.bat` from the zip file with the CMake delivered by the installer, I get the following output:
~~~
cmake version 3.21.3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
-- Building for: Visual Studio 16 2019
-- The C compiler identification is MSVC 19.29.30136.0
-- The CXX compiler identification is MSVC 19.29.30136.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/Community/VC/Tools/MSVC/14.29.30133/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/Community/VC/Tools/MSVC/14.29.30133/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: XXXX/CMake-permissions/out
-- Install configuration: "Release"
-- Installing: XXXX/CMake-permissions/install/bin/test.sh
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: XXXX-XXXX
Verzeichnis von XXXX\CMake-permissions\install\bin
15.10.2021 10:40 <DIR> .
15.10.2021 10:40 <DIR> ..
15.10.2021 10:04 11 test.sh
1 Datei(en), 11 Bytes
2 Verzeichnis(se), XXXX Bytes frei
~~~
Executing the same batch file with the PATH variable pointing to an executable of CMake 3.21.3 I built myself using Vustial Studio 16.11.4, I get the following output (Sorry about the German):
~~~
cmake version 3.21.3
CMake suite maintained and supported by Kitware (kitware.com/cmake).
-- Building for: Visual Studio 16 2019
-- The C compiler identification is MSVC 19.29.30136.0
-- The CXX compiler identification is MSVC 19.29.30136.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/Community/VC/Tools/MSVC/14.29.30133/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/Community/VC/Tools/MSVC/14.29.30133/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: XXXX/CMake-permissions/out
-- Install configuration: "Release"
-- Installing: XXXX/CMake-permissions/install/bin/test.sh
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: XXXX-XXXX
Verzeichnis von XXXX\CMake-permissions\install\bin
15.10.2021 10:43 <DIR> .
15.10.2021 10:43 <DIR> ..
15.10.2021 10:04 11 test.sh
5 test.sh:cmake_mode_t:$DATA
1 Datei(en), 11 Bytes
2 Verzeichnis(se), XXXX Bytes frei
~~~
As you can see, the listings at the end differ, in that the custom built version of CMake correctly added an ADS stream `test.sh:cmake_mode_t:$DATA` containing the permissions. The CMake from the installer, however, did not.3.21.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22905Clang: CMake generates -flto instead of -flto=thin on Windows2021-11-16T09:06:14-05:00Robin ChristClang: CMake generates -flto instead of -flto=thin on WindowsOn Windows, CMake incorrectly generates
```
-O3 -DNDEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -O3 -fno-math-errno -flto -fvisibility-inlines-hidden -march=core-avx2
```
On Linux we get the expected result
```
-O3 -DNDEBUG -O3 -fno...On Windows, CMake incorrectly generates
```
-O3 -DNDEBUG -D_DLL -D_MT -Xclang --dependent-lib=msvcrt -O3 -fno-math-errno -flto -fvisibility-inlines-hidden -march=core-avx2
```
On Linux we get the expected result
```
-O3 -DNDEBUG -O3 -fno-math-errno -flto=thin -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -march=core-avx2
```
(dumped via `CMAKE_EXPORT_COMPILE_COMMANDS`)
If I read the CMake source correctly, that is not supposed to happen?
```
cmake version 3.22.0-rc2
```
```
clang version 12.0.1
Target: x86_64-pc-windows-msvc
Thread model: posix
InstalledDir: C:\Program Files\LLVM\bin
```
`ninja 1.10.2`
Compiler is recognised as
```
-- The C compiler identification is Clang 12.0.1 with GNU-like command-line
-- The CXX compiler identification is Clang 12.0.1 with GNU-like command-line
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/Program Files/LLVM/bin/clang.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/Program Files/LLVM/bin/clang++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
```
LTO is enabled via `set(CMAKE_INTERPROCEDURAL_OPTIMIZATION TRUE)`3.23.0Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/22743find_program fails when looking for programs installed from Microsoft Store, ...2021-11-02T08:51:40-04:00Yuriy O'Donnellfind_program fails when looking for programs installed from Microsoft Store, such as pwshHi,
There appears to be an issue affecting users on Windows when find_program is used to find something installed from the MS Store, for example PowerShell used by vcpkg: https://github.com/microsoft/vcpkg/issues/15681#issuecomment-9397...Hi,
There appears to be an issue affecting users on Windows when find_program is used to find something installed from the MS Store, for example PowerShell used by vcpkg: https://github.com/microsoft/vcpkg/issues/15681#issuecomment-939781072
Store apps create "App Execution Aliases" in `%LOCALAPPDATA%\Microsoft\WindowsApps`, which is added to `%PATH%`.
As far as I understand, SystemTools::FileExists() (and maybe FileIsExecutable() as well as any other similar function) would need to follow the alias links instead of attempting to CreateFile() on the alias itself, which fails and causes false negative find_program result.
The app execution alias has the FILE_ATTRIBUTE_REPARSE_POINT attribute. Adding FILE_FLAG_OPEN_REPARSE_POINT to CreateFileW() in SystemTools::FileExists() will _probably_ fix the issue. Without it, one just gets ERROR_CANT_ACCESS_FILE.3.23.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21639VS: CMake does not find portable instance2022-02-09T09:44:00-05:00Tim SparklesVS: CMake does not find portable instanceRepro:
1) Install Visual Studio Build Tools
2) Copy the contents of the install directory (e.g. c:\program files (x86)\Microsoft Visual Studio\2019\BuildTools) to a version-controlled location, e.g. c:\depot\buildtools
3) `cmake -DCMAKE_...Repro:
1) Install Visual Studio Build Tools
2) Copy the contents of the install directory (e.g. c:\program files (x86)\Microsoft Visual Studio\2019\BuildTools) to a version-controlled location, e.g. c:\depot\buildtools
3) `cmake -DCMAKE_GENERATOR_INSTANCE=c:\depot\buildtools`
Expected result:
cmake finds the build tools in the specified location
Actual result:
- cmake doesn't even look in the specified location (confirmed with procmon.exe)
- "could not find specified instance of Visual Studio"
One of our engineering pillars is that we can build and run our software having only a version control client installed on the build machine. It seems that cmake expects Visual Studio to be fully installed, and enforces this by querying C:\ProgramData and the registry. These queries should not be necessary when a specific instance location is explicitly provided.3.23.0Brad KingBrad Kinghttps://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/23781cmake -E create_symlink with .. in path create broken junction2022-08-02T09:28:54-04:00Dusan Poizlcmake -E create_symlink with .. in path create broken junctionHello,
we are using cmake -E create_symlink in our project. Up until now it was working fine but with 3.24 we encountered problem on Windows with it.
we are calling it with "${CMAKE_SOURCE_DIR}/../UserData" as target to link. This is wor...Hello,
we are using cmake -E create_symlink in our project. Up until now it was working fine but with 3.24 we encountered problem on Windows with it.
we are calling it with "${CMAKE_SOURCE_DIR}/../UserData" as target to link. This is working fine with older releases at it create symlink. With 3.24 it create junction which is not problem itself it just that junction doesn't like ".." in its path. I think cmake -E create_symlink should always create symlink on windows or normalize path when creating junction.3.24.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23542MSYS/MinGW Makfiles: Hardcoded gcc/g++ does not exist on MINGW/CLANG2022-05-27T09:09:26-04:00مهدي شينون (Mehdi Chinoune)MSYS/MinGW Makfiles: Hardcoded gcc/g++ does not exist on MINGW/CLANG```CMake
cmake_minimum_required(VERSION 3.16)
project(test CXX)
add_executable(main main.cpp)
```
The clang++ compiler is in PATH:
```
$ whereis clang++
clang++: /clang64/bin/clang++.exe
```
"MSYS Makefiles"
```
$ cmake -B build/msys -G"...```CMake
cmake_minimum_required(VERSION 3.16)
project(test CXX)
add_executable(main main.cpp)
```
The clang++ compiler is in PATH:
```
$ whereis clang++
clang++: /clang64/bin/clang++.exe
```
"MSYS Makefiles"
```
$ cmake -B build/msys -G"MSYS Makefiles"
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
The CMAKE_CXX_COMPILER:
g++.exe
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "D:/dev/Bugs/cmake_code/build/msys/CMakeFiles/CMakeOutput.log".
See also "D:/dev/Bugs/cmake_code/build/msys/CMakeFiles/CMakeError.log".
```
"MinGW Makefiles":
```
$ cmake -B build/mingw -G"MinGW Makefiles"
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
The CMAKE_CXX_COMPILER:
g++.exe
is not a full path and was not found in the PATH.
Tell CMake where to find the compiler by setting either the environment
variable "CXX" or the CMake cache entry CMAKE_CXX_COMPILER to the full path
to the compiler, or to the compiler name if it is in the PATH.
-- Configuring incomplete, errors occurred!
See also "D:/dev/Bugs/cmake_code/build/mingw/CMakeFiles/CMakeOutput.log".
See also "D:/dev/Bugs/cmake_code/build/mingw/CMakeFiles/CMakeError.log".
```
That's because the c/c++ compiler executable names are hardcoded for these generators:
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.23.1/Source/cmGlobalMSYSMakefileGenerator.cxx#L54
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.23.1/Source/cmGlobalMinGWMakefileGenerator.cxx#L32
I think these lines should be removed to let cmake searches for C/C++ compiler like any other generator (skip https://gitlab.kitware.com/cmake/cmake/-/blob/v3.23.1/Modules/CMakeDetermineCXXCompiler.cmake#L53 and https://gitlab.kitware.com/cmake/cmake/-/blob/v3.23.1/Modules/CMakeDetermineCCompiler.cmake#L54)3.24.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22367Windows on ARM, Support?2022-06-14T16:33:45-04:00sidd-kishanWindows on ARM, Support?Please let us know when can we have an ARM64 version for Windows on ARM OS. We can help you test We have Windows on Rasberry Pi setup. Please pursue it we at Windows on Rasberry Pi community will be glad to extend support in testing your...Please let us know when can we have an ARM64 version for Windows on ARM OS. We can help you test We have Windows on Rasberry Pi setup. Please pursue it we at Windows on Rasberry Pi community will be glad to extend support in testing your drivers and tools for ARM64.3.24.0https://gitlab.kitware.com/cmake/cmake/-/issues/17904Use external/system includes feature from Visual Studio 15.62022-10-21T11:16:27-04:00RichardUse external/system includes feature from Visual Studio 15.6In response of gcc/clang's command switch "-isystem" VS2017 v15.6 gained a new switch "/external:I" for supporting external/system include paths to prevent warning from third-party headers.
CMake should make use of it.
A closer descript...In response of gcc/clang's command switch "-isystem" VS2017 v15.6 gained a new switch "/external:I" for supporting external/system include paths to prevent warning from third-party headers.
CMake should make use of it.
A closer description can be found here: https://blogs.msdn.microsoft.com/vcblog/2017/12/13/broken-warnings-theory/3.24.0https://gitlab.kitware.com/cmake/cmake/-/issues/23841Modules/Platform/Windows-GNU.cmake: _CMAKE_TOOLCHAIN_PREFIX on windres2022-11-28T17:52:39-05:00B. Scott MichelModules/Platform/Windows-GNU.cmake: _CMAKE_TOOLCHAIN_PREFIX on windresI just encountered this in 3.24.0 after a recent upgrade. No Cygwin or MinGW toolchain distributes a version of `windres` with the toolchain prefix prepended; Linux packages sometimes have a prepended toolchain name for cross-compiles. T...I just encountered this in 3.24.0 after a recent upgrade. No Cygwin or MinGW toolchain distributes a version of `windres` with the toolchain prefix prepended; Linux packages sometimes have a prepended toolchain name for cross-compiles. There have been proposals to do this for Windows-native, but it's never been done AFAIK.
The "solution" is to manually copy `windres` to `<toolchain prefix>-windres`, which is really suboptimal and breaks packaging badly.
This change now breaks all of my MinGW builds on Windows.3.24.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23836IPO: gcc -flto=auto breaks linking on Windows2022-08-15T10:48:31-04:00Brad KingIPO: gcc -flto=auto breaks linking on Windows!7400 switched from `-flto` to `-flto=auto` for #23640, but according to https://gitlab.kitware.com/cmake/cmake/-/issues/23640#note_1227490 the latter flag breaks linking on Windows.!7400 switched from `-flto` to `-flto=auto` for #23640, but according to https://gitlab.kitware.com/cmake/cmake/-/issues/23640#note_1227490 the latter flag breaks linking on Windows.3.24.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23880source_group and target_sources with file_set headers conflict2022-08-25T09:14:27-04:00Bert de Vreugdsource_group and target_sources with file_set headers conflictIn one of my projects I have a cmake file, containing:
```cmake
target_sources(exampleproject
PUBLIC FILE_SET HEADERS FILES
ExampleHeader.h
PUBLIC FILE_SET examplelib TYPE HEADERS BASE_DIRS examplelib/include FILES
...In one of my projects I have a cmake file, containing:
```cmake
target_sources(exampleproject
PUBLIC FILE_SET HEADERS FILES
ExampleHeader.h
PUBLIC FILE_SET examplelib TYPE HEADERS BASE_DIRS examplelib/include FILES
${headers_examplelib}
)
source_group(TREE ${CMAKE_CURRENT_SOURCE_DIR}/examplelib/include PREFIX "Header Files/examplelib" FILES ${headers_examplelib})
```
However, if I generate a Visual Studio solution (`cmake -G "Visual Studio 17 2022" -A x64 ..`), the subgroup is not created under `Header Files` (every file will be added to the root of `Header Files`).
When I change `Header Files` to an other value ~~(including `Source Files`)~~ it will work. When adding non-header files to another subdirectory of a default source group (like `Source Files`) will also work.
My belief is that the fileset generated by target_sources somehow conflict with the settings inside source_group?3.24.2Kyle EdwardsKyle Edwardshttps://gitlab.kitware.com/cmake/cmake/-/issues/24089Ninja: UTF-8 filenames don't work anymore on windows with ninja 1.102022-11-01T11:06:49-04:00Aaron SiegelNinja: UTF-8 filenames don't work anymore on windows with ninja 1.10We have a file named "Kodak® T-Max 100.tif" that gets copied with a custom build command like this
```
set(SOURCE_FILE "${CMAKE_CURRENT_SOURCE_DIR}/Kodak® T-Max 100.tif")
get_filename_component(SOURCE_FILENAME "${SOURCE_FILE}" NAME)
s...We have a file named "Kodak® T-Max 100.tif" that gets copied with a custom build command like this
```
set(SOURCE_FILE "${CMAKE_CURRENT_SOURCE_DIR}/Kodak® T-Max 100.tif")
get_filename_component(SOURCE_FILENAME "${SOURCE_FILE}" NAME)
set(OUTPUT_FILE "${CMAKE_CURRENT_BINARY_DIR}/${SOURCE_FILENAME}")
add_custom_command(OUTPUT "${OUTPUT_FILE}"
COMMAND "${CMAKE_COMMAND}" -E copy_if_different "${SOURCE_FILE}" "${OUTPUT_FILE}"
MAIN_DEPENDENCY "${SOURCE_FILE}"
VERBATIM
)
target_sources(${TARGET_NAME} PRIVATE "${OUTPUT_FILE}")
source_group("Generated Files" FILES "${OUTPUT_FILE}")
```
On macOS this works fine for all versions of CMake, on Windows this works fine for CMake 3.21.7, but with CMake 3.24.2 it doesn't work anymore on windows using Ninja or MSVC (I assume it broke before that just not sure when)3.23.5Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24068Ninja: Lots of showInclude logs due to encoding msvc_deps_prefix to utf-82022-10-31T09:44:16-04:00kangjianbinNinja: Lots of showInclude logs due to encoding msvc_deps_prefix to utf-8This original issue was reported in https://github.com/ninja-build/ninja/issues/613
Looks like the regression was introduced in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5860.
> CMake can detect the prefix correctly, and...This original issue was reported in https://github.com/ninja-build/ninja/issues/613
Looks like the regression was introduced in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/5860.
> CMake can detect the prefix correctly, and stores it in its variable 'CMAKE_CL_SHOWINCLUDES_PREFIX' (or CMAKE_CXX_CL_SHOWINCLUDES_PREFIX). Note that this prefix is not utf-8 encoding. For example, in my locale it is encoded in 'GB18030'.
>
> However, when creating rules.ninja, cmake converts this prefix to utf-8 and saves the converted data to msvc_deps_prefix.
>
> During build, msvc_deps_prefix (utf-8 encoding) cannot match MSVC's output (gb18030 enconding, et al), so Ninja reports lots of include files.
I switched to cmake-3.20, which doesn't convert the prefix to utf-8, and everything works well.3.25.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23741IntelLLVM: IPO fails on Windows2022-08-04T09:50:25-04:00Martin BlanchardIntelLLVM: IPO fails on WindowsThe CMake sample below fails on Windows with MSVC 2019 (16.11.7) + IntelLLVM 2022.1 (2022.1.0.20220316):
```cmake
cmake_minimum_required(
VERSION 3.24.0)
set(CMAKE_C_COMPILER "icx")
set(CMAKE_CXX_COMPILER "icx")
enable_language(C CX...The CMake sample below fails on Windows with MSVC 2019 (16.11.7) + IntelLLVM 2022.1 (2022.1.0.20220316):
```cmake
cmake_minimum_required(
VERSION 3.24.0)
set(CMAKE_C_COMPILER "icx")
set(CMAKE_CXX_COMPILER "icx")
enable_language(C CXX)
project(CMake-IntelLLVM-WIN32)
include(CheckIPOSupported)
check_ipo_supported()
```
Ran like:
```bat
cmake -G Ninja -B build\ .
```
Gives:
```
-- The C compiler identification is IntelLLVM 2022.1.0 with MSVC-like command-line
-- The CXX compiler identification is IntelLLVM 2022.1.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)/Intel/oneAPI/compiler/latest/windows/bin/icx.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)/Intel/oneAPI/compiler/latest/windows/bin/icx.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Error at D:/.../cmake-3.24/Modules/CheckIPOSupported.cmake:68 (message):
IPO is not supported (CMake doesn't support IPO for current CXX compiler).
Call Stack (most recent call first):
D:/.../cmake-3.24/Modules/CheckIPOSupported.cmake:245 (_ipo_not_supported)
CMakeLists.txt:12 (check_ipo_supported)
-- Configuring incomplete, errors occurred!
See also "D:/.../build/CMakeFiles/CMakeOutput.log".
```
[CMakeOutput.log](/uploads/aa30b9d436e9e04640f177a2fbcfd680/CMakeOutput.log)3.25.0https://gitlab.kitware.com/cmake/cmake/-/issues/24316IntelLLVM: Windows: emits -Qstd=c++11 that causes compiler warnings2023-01-13T08:43:35-05:00scivisionIntelLLVM: Windows: emits -Qstd=c++11 that causes compiler warningsWindows IntelLLVM emits `-Qstd=` flags that cause compiler warnings. This is annoying in general and a problem when using COMPILE_WARNING_AS_ERROR.
This is observed with generators MinGW Makefiles and Ninja. This is not observed with ge...Windows IntelLLVM emits `-Qstd=` flags that cause compiler warnings. This is annoying in general and a problem when using COMPILE_WARNING_AS_ERROR.
This is observed with generators MinGW Makefiles and Ninja. This is not observed with generator Visual Studio 17 2022.
However, @brad.king notes that
> We *strongly* prefer the `-` style options over `/` because they work better with makefiles that use the MSYS shell.
```cmake
cmake_minimum_required(VERSION 3.21)
project(dummy LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 11)
set(cpp_src "${CMAKE_CURRENT_BINARY_DIR}/dummy.cpp")
file(WRITE ${cpp_src} "int main() { return 0; }")
add_executable(dummy_cpp ${cpp_src})
```
```
-- The CXX compiler identification is IntelLLVM 2023.0.0 with MSVC-like command-line
```
Ninja:
```
[1/2] Building CXX object CMakeFiles\dummy_cpp.dir\dummy.cpp.obj
icx: warning: argument unused during compilation: '-Qstd:c++11' [-Wunused-command-line-argument]
[2/2] Linking CXX executable dummy_cpp.exe
```
MinGW Makefiles:
```
[ 50%] Building CXX object CMakeFiles/dummy_cpp.dir/dummy.cpp.obj
icx: warning: argument unused during compilation: '-Qstd=c++11' [-Wunused-command-line-argument]
[100%] Linking CXX executable dummy_cpp.exe
[100%] Built target dummy_cpp
```3.25.2