CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2022-02-18T03:33:52-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/23245[MSVC, cmake 3.23.0-rc1] ExternalProject_Add seems not to be using SOURCE_SUB...2022-02-18T03:33:52-05:00Alexander Mitin[MSVC, cmake 3.23.0-rc1] ExternalProject_Add seems not to be using SOURCE_SUBDIR argumentWe use LLVM as a part of our project. We prebuild it using ExternalProject with following cmake script:
<details><summary>LLVM ExternalProject config</summary>
```cmake
ExternalProject_Add(
LLVM
GIT_REPOSITORY https://github.com/ll...We use LLVM as a part of our project. We prebuild it using ExternalProject with following cmake script:
<details><summary>LLVM ExternalProject config</summary>
```cmake
ExternalProject_Add(
LLVM
GIT_REPOSITORY https://github.com/llvm/llvm-project.git
GIT_TAG tags/llvmorg-10.0.0
GIT_SHALLOW true
GIT_PROGRESS true
UPDATE_COMMAND ""
PATCH_COMMAND ""
SOURCE_DIR ${LLVM_SOURCE_DIR}
SOURCE_SUBDIR llvm
BINARY_DIR ${LLVM_BUILD_DIR}
STAMP_DIR ${LLVM_DIR}/timestamps
EXCLUDE_FROM_ALL 1
INSTALL_DIR ${LLVM_INSTALL_PREFIX}
CMAKE_GENERATOR ${CMAKE_GENERATOR}
CMAKE_ARGS ${LLVM_ARGS}
TEST_COMMAND ""
LIST_SEPARATOR ,
)
```
</details>
Where LLVM_SOURCE_DIR is `C:/Users/user/code/llvm/source`, and LLVM project is a sub-directory there.
This pulls the entire LLVM repo, but as we need to build the LLVM project only we use SOURCE_SUBDIR argument.
The script works fine with cmake 3.22.2, but for cmake 3.23.0-rc1 we get this at the build step
```
1>CUSTOMBUILD : CMake error : The source directory "C:/Users/user/code/llvm/source" does not appear to contain CMakeLists.txt.[C:\Users\user\code\build\thirdparty\llvm\LLVM.vcxproj]
```
The expected LLVM source directory should be `C:/Users/user/code/llvm/source/llvm`, but it is not.Craig ScottCraig Scotthttps://gitlab.kitware.com/cmake/cmake/-/issues/232433.23.0-rc1: Regression using CUDA_ARCHITECTURES with nvcc 11.5+2022-02-22T12:56:55-05:00Kevin Leonardic3.23.0-rc1: Regression using CUDA_ARCHITECTURES with nvcc 11.5+Specifying CMAKE_CUDA_ARCHITECTURES before target creation or setting the target property CUDA_ARCHITECTURES does not affect compilation options passed to nvcc. With CMake 3.22.2 it works as expected.
Generator: Visual Studio 17 2022
C...Specifying CMAKE_CUDA_ARCHITECTURES before target creation or setting the target property CUDA_ARCHITECTURES does not affect compilation options passed to nvcc. With CMake 3.22.2 it works as expected.
Generator: Visual Studio 17 2022
CUDA version: 11.6
Here is a small example CMakeLists.txt:
```
cmake_minimum_required(VERSION 3.23)
set(CMAKE_CUDA_ARCHITECTURES 75)
project(example LANGUAGES CUDA)
set(src "${CMAKE_CURRENT_BINARY_DIR}/main.cu")
file(CONFIGURE OUTPUT ${src} CONTENT "int main(){}")
add_executable(test ${src})
set_target_properties(test PROPERTIES CUDA_ARCHITECTURES "75")
```
This is the resulting compiler invocation:
`"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.6\bin\nvcc.exe" -gencode=arch=compute_52,code=\"sm_52,compute_52\" --use-local-env -ccbin "C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.31.31103\bin\HostX64\x64" -x cu -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.6\include" --keep-dir x64\Debug -maxrregcount=0 --machine 64 --compile -cudart static -Xcompiler="/EHsc -Zi -Ob0" -g -D_WINDOWS -D"CMAKE_INTDIR=\"Debug\"" -D_MBCS -D"CMAKE_INTDIR=\"Debug\"" -Xcompiler "/EHsc /W1 /nologo /Od /Fdtest.dir\Debug\vc143.pdb /FS /Zi /RTC1 /MDd " -o test.dir\Debug\main.obj "D:\build\bad_cuda_architectures\main.cu"`
The bad part:
`-gencode=arch=compute_52,code=\"sm_52,compute_52\"`3.23.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/232383.23.0-rc1: First of multiple source paths used instead of last2022-03-17T15:17:59-04:00Aaron Brayaaron.bray@kitware.com3.23.0-rc1: First of multiple source paths used instead of last
I am building my 4.x branch of https://gitlab.kitware.com/physiology/engine
This has a superbuild that will pull and build Eigen as part of the outer build
Configure/Generate a Visual Studio 2019 project (I am using 16.11.10) with pro...
I am building my 4.x branch of https://gitlab.kitware.com/physiology/engine
This has a superbuild that will pull and build Eigen as part of the outer build
Configure/Generate a Visual Studio 2019 project (I am using 16.11.10) with project defaults
Open project and Build Solution
The build starts by pulling Eigen, and when it starts a build, it is trying to find this non existent source directory
```
CMake error : The source directory "N:/builds/pulse-engine-bug/External/Eigen3/build/Visual Studio 16 2019" does not exist.
```
When using CMake 3.22.2, Eigen's source directory is `N:/builds/pulse-engine/External/Eigen3/src`
and build directory is : `N:/builds/pulse-engine/External/Eigen3/build/`
This new version seems to be trying to postfix the generator to the eigen path somewhere when it should not be?3.23.0Robert MaynardRobert Maynardhttps://gitlab.kitware.com/cmake/cmake/-/issues/23229FindGLUT regression on Windows when `glut` can be found via pkg-config2022-02-16T09:42:58-05:00Silvio TraversaroFindGLUT regression on Windows when `glut` can be found via pkg-configI experience a regression in CMake 3.22 due to https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6251 .
When compiling an executable that links `GLUT::GLUT` in a Windows conda environment in which `glut` can be found via `pkg-co...I experience a regression in CMake 3.22 due to https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6251 .
When compiling an executable that links `GLUT::GLUT` in a Windows conda environment in which `glut` can be found via `pkg-config`, the link fails with error:
~~~
2022-02-14T21:37:34.2592278Z D:\a\robotology-superbuild\robotology-superbuild\src\ICUB\src\tools\iCubGui\src\bvhnoderoot.h(53,1): warning C4305: 'argument': truncation from 'double' to 'GLfloat' [D:\a\robotology-superbuild\robotology-superbuild\build\src\ICUB\src\tools\iCubGui\src\iCubGui.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\ICUB.vcxproj]
2022-02-14T21:37:34.2608306Z D:\a\robotology-superbuild\robotology-superbuild\src\ICUB\src\tools\iCubGui\src\bvh.h(147,1): warning C4305: 'initializing': truncation from 'double' to 'GLfloat' [D:\a\robotology-superbuild\robotology-superbuild\build\src\ICUB\src\tools\iCubGui\src\iCubGui.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\ICUB.vcxproj]
2022-02-14T21:37:34.2611102Z D:\a\robotology-superbuild\robotology-superbuild\src\ICUB\src\tools\iCubGui\src\bvh.h(148,1): warning C4305: 'initializing': truncation from 'double' to 'GLfloat' [D:\a\robotology-superbuild\robotology-superbuild\build\src\ICUB\src\tools\iCubGui\src\iCubGui.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\ICUB.vcxproj]
2022-02-14T21:37:34.2615673Z D:\a\robotology-superbuild\robotology-superbuild\src\ICUB\src\tools\iCubGui\src\bvh.h(149,1): warning C4305: 'initializing': truncation from 'double' to 'GLfloat' [D:\a\robotology-superbuild\robotology-superbuild\build\src\ICUB\src\tools\iCubGui\src\iCubGui.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\ICUB.vcxproj]
2022-02-14T21:37:35.1301414Z Generating Code...
2022-02-14T21:37:38.1367825Z LINK : warning LNK4044: unrecognized option '/LC:/Miniconda3/envs/test/Library/lib'; ignored [D:\a\robotology-superbuild\robotology-superbuild\build\src\ICUB\src\tools\iCubGui\src\iCubGui.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\ICUB.vcxproj]
2022-02-14T21:37:38.1369220Z LINK : warning LNK4044: unrecognized option '/lglut'; ignored [D:\a\robotology-superbuild\robotology-superbuild\build\src\ICUB\src\tools\iCubGui\src\iCubGui.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\ICUB.vcxproj]
2022-02-14T21:37:38.1370530Z LINK : warning LNK4044: unrecognized option '/lopengl32'; ignored [D:\a\robotology-superbuild\robotology-superbuild\build\src\ICUB\src\tools\iCubGui\src\iCubGui.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\ICUB.vcxproj]
2022-02-14T21:37:38.1371705Z LINK : warning LNK4044: unrecognized option '/lwinmm'; ignored [D:\a\robotology-superbuild\robotology-superbuild\build\src\ICUB\src\tools\iCubGui\src\iCubGui.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\ICUB.vcxproj]
2022-02-14T21:37:38.1372843Z LINK : warning LNK4044: unrecognized option '/lgdi32'; ignored [D:\a\robotology-superbuild\robotology-superbuild\build\src\ICUB\src\tools\iCubGui\src\iCubGui.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\ICUB.vcxproj]
2022-02-14T21:37:38.1374618Z LINK : warning LNK4044: unrecognized option '/lm'; ignored [D:\a\robotology-superbuild\robotology-superbuild\build\src\ICUB\src\tools\iCubGui\src\iCubGui.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\ICUB.vcxproj]
2022-02-14T21:37:38.2235806Z LINK : fatal error LNK1181: cannot open input file 'glut.lib' [D:\a\robotology-superbuild\robotology-superbuild\build\src\ICUB\src\tools\iCubGui\src\iCubGui.vcxproj] [D:\a\robotology-superbuild\robotology-superbuild\build\ICUB.vcxproj]
~~~
The problem is that https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6251 is propagating the low-level LDFLAGS and Compilation flags to the compiler that are not platform indipendent, instead of propagating platform indipendent properfies such as library directories.3.22.3https://gitlab.kitware.com/cmake/cmake/-/issues/23217cmake: Handling of argument ""2022-07-20T07:03:07-04:00Arfrevercmake: Handling of argument ""In cmake 3.23.0-rc1, ~~`cmake path-to-source-directory` (without -S) fails~~.
Originally reported in https://bugs.gentoo.org/833100 where cmake invocation and output was (with later correction):
```
cmake -C /var/tmp/portage/dev-util/cm...In cmake 3.23.0-rc1, ~~`cmake path-to-source-directory` (without -S) fails~~.
Originally reported in https://bugs.gentoo.org/833100 where cmake invocation and output was (with later correction):
```
cmake -C /var/tmp/portage/dev-util/cmake-3.23.0_rc1/work/cmake-3.23.0-rc1_build/gentoo_common_config.cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_USE_SYSTEM_LIBRARIES=ON -DCMAKE_DOC_DIR=/share/doc/cmake-3.23.0_rc1 -DCMAKE_MAN_DIR=/share/man -DCMAKE_DATA_DIR=/share/cmake -DSPHINX_MAN=no -DSPHINX_HTML=no -DBUILD_CursesDialog=yes -DBUILD_TESTING=no -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_TOOLCHAIN_FILE=/var/tmp/portage/dev-util/cmake-3.23.0_rc1/work/cmake-3.23.0-rc1_build/gentoo_toolchain.cmake "" /var/tmp/portage/dev-util/cmake-3.23.0_rc1/work/cmake-3.23.0-rc1
CMake Warning:
Ignoring extra path from command line:
/var/tmp/portage/dev-util/cmake-3.23.0_rc1/work/cmake-3.23.0-rc1
loading initial cache file /var/tmp/portage/dev-util/cmake-3.23.0_rc1/work/cmake-3.23.0-rc1_build/gentoo_common_config.cmake
CMake Error: The source directory "/tmp/portage/dev-util/cmake-3.23.0_rc1/work/cmake-3.23.0-rc1_build" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
```
Argument `/var/tmp/portage/dev-util/cmake-3.23.0_rc1/work/cmake-3.23.0-rc1` was incorrectly not recognized as path to source directory (and was treated as "extra path" in "Ignoring extra path from command line" warning), and then current working directory (`/tmp/portage/dev-util/cmake-3.23.0_rc1/work/cmake-3.23.0-rc1_build`) was used as source directory.
I guess that this ~~regression~~ change was introduced in one of these commits:
* https://gitlab.kitware.com/cmake/cmake/-/commit/b2bc3364f0c220f560e4cf09b56b8486d8bfddfe
* https://gitlab.kitware.com/cmake/cmake/-/commit/eacf1f879b0933509efbd4fb4d6d72ce99412aa7
As found later, effectively `cmake "" path-to-source-directory` was actually run, and `""` tricked some logic in CMake.3.23.0Robert MaynardRobert Maynardhttps://gitlab.kitware.com/cmake/cmake/-/issues/232033.23.0-rc1: Regression in target_link_libraries genex with multiple libs2022-02-22T15:03:11-05:00Gregor Jasny3.23.0-rc1: Regression in target_link_libraries genex with multiple libsHello,
while testing CMake 3.23.0-rc1 we found the following regression:
```cmake
cmake_minimum_required(VERSION 3.22)
project(testcase LANGUAGES C)
find_package(CURL REQUIRED)
find_package(ZLIB REQUIRED)
set(MY_LIBRARIES CURL::libc...Hello,
while testing CMake 3.23.0-rc1 we found the following regression:
```cmake
cmake_minimum_required(VERSION 3.22)
project(testcase LANGUAGES C)
find_package(CURL REQUIRED)
find_package(ZLIB REQUIRED)
set(MY_LIBRARIES CURL::libcurl ZLIB::ZLIB)
add_library(testcase STATIC foo.c)
target_link_libraries(testcase INTERFACE $<BUILD_INTERFACE:${MY_LIBRARIES}>)
install(TARGETS testcase EXPORT Testcase)
install(EXPORT Testcase DESTINATION foo)
```
This leads to the following error during generation (Ninja in our case):
```
CMake Error at CMakeLists.txt:12 (target_link_libraries):
The link interface of target "testcase" contains:
$<BUILD_INTERFACE:CURL::libcurl
but the target was not found. Possible reasons include:
* There is a typo in the target name.
* A find_package call is missing for an IMPORTED target.
* An ALIAS target is missing.
```
The error vanishes if `MY_LIBRARIES` only contains a single library.
Could you please take a look?
Thanks,
Gregor3.23.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23183install(... INCLUDES DESTINATION ...) is accumlating include directories acro...2022-02-10T09:07:40-05:00Rob Unokiinstall(... INCLUDES DESTINATION ...) is accumlating include directories across multiple exportsWhen I call `install(TARGETS targetname EXPORT exportname INCLUDES DESTINATION ....)` for the same target across more than one export with include directories specified, the generated import target in each of the resultant export cmake ...When I call `install(TARGETS targetname EXPORT exportname INCLUDES DESTINATION ....)` for the same target across more than one export with include directories specified, the generated import target in each of the resultant export cmake scripts contains all of the destination subdirectories for all of the install calls. My expected result (and the prior behvior) is that the export scripts would only specify the include dirs for the matching install call.
Here's a minimal repro
```cmake
cmake_minimum_required(VERSION 3.19)
project(cmake-install-include-dir-repro LANGUAGES C)
add_library(testlib STATIC test_func.c)
install(
EXPORT pkg1
FILE pkg1Config.cmake
DESTINATION pkg1/cmake
NAMESPACE pkg1::
)
install(
TARGETS testlib EXPORT pkg1
ARCHIVE DESTINATION pkg1/lib
INCLUDES DESTINATION pkg1/inc
)
install(
EXPORT pkg2
FILE pkg2Config.cmake
DESTINATION pkg2/cmake
NAMESPACE pkg2::
)
install(
TARGETS testlib EXPORT pkg2
ARCHIVE DESTINATION pkg2/lib
INCLUDES DESTINATION pkg2/inc
)
```
The resultant contents of pkg1/cmake/pkg1Config.cmake
```cmake
# Create imported target pkg1::testlib
add_library(pkg1::testlib STATIC IMPORTED)
set_target_properties(pkg1::testlib PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/pkg1/inc;${_IMPORT_PREFIX}/pkg2/inc"
)
```
and similarly the resultant contents for pkg2/cmake/pkg2Config.cmake
```cmake
# Create imported target pkg2::testlib
add_library(pkg2::testlib STATIC IMPORTED)
set_target_properties(pkg2::testlib PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/pkg1/inc;${_IMPORT_PREFIX}/pkg2/inc"
)
```
The behavior above occurs in 3.22.2
This does not occur with 3.19 where each pkg#Config.cmake only contains a single include directory. While I haven't verified directly myself, a colleague reports the 3.19 behavior on 3.21.3.22.3https://gitlab.kitware.com/cmake/cmake/-/issues/23155message: output on stderr jumbled with stdout2022-02-01T12:37:35-05:00Brad Kingmessage: output on stderr jumbled with stdoutIn a case observed with CMake 3.21.2 [here](https://testing.sandia.gov/cdash/test/113234281), when the `cmake` command-line tool's stdout and stderr are both connected to the same file descriptor, the `-- Configuring done` line on stdout...In a case observed with CMake 3.21.2 [here](https://testing.sandia.gov/cdash/test/113234281), when the `cmake` command-line tool's stdout and stderr are both connected to the same file descriptor, the `-- Configuring done` line on stdout can be jumbled with `message()` content on stderr:
```
TribitsHelloWorld_INSTALL_DIR = ...
Tr-- Configuring done
ibitsHelloWorld_INCLUDE_DIRS = ...
```3.21.5Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23147IAR: CXX support assumes CMP00572022-01-31T10:31:35-05:00Raul Tambreraul@tambre.eeIAR: CXX support assumes CMP0057Commit a9073db736f6388f10f914c7361cc374f7522073 added use of the `IN_LIST` operator in an `if()`. The code doesn't work if `CMP0057` isn't set to `NEW` by user code.
Reported in https://gitlab.kitware.com/cmake/cmake/-/issues/23146#note...Commit a9073db736f6388f10f914c7361cc374f7522073 added use of the `IN_LIST` operator in an `if()`. The code doesn't work if `CMP0057` isn't set to `NEW` by user code.
Reported in https://gitlab.kitware.com/cmake/cmake/-/issues/23146#note_11330823.22.3Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/23143NMake: UTF-8 BOM breaks Raspberry PI Pico build on Windows2022-02-01T12:37:03-05:00Peter LaudyNMake: UTF-8 BOM breaks Raspberry PI Pico build on WindowsI'm using VS Code to build a C++ project for the Raspberry PI Pico. Set everything up like described in the RP documentation. When using CMake with a version newer than 3.20.6 I get the following error during the build:
```
[build] [ 13...I'm using VS Code to build a C++ project for the Raspberry PI Pico. Set everything up like described in the RP documentation. When using CMake with a version newer than 3.20.6 I get the following error during the build:
```
[build] [ 13%] Linking CXX executable pico_cnc.elf
[build] AR10B2~1.EXE: error: CMakeFiles/pico_cnc.dir/program.cpp.obj: No such file or directory
[build] NMAKE : fatal error U1077: 'C:\PROGRA~2\GNUARM~1\102020~1\bin\AR10B2~1.EXE' : return code '0x1'
[build] Stop.
```
The garbled output on the second line just before `CMakeFiles` is the BOM of the file containing a list of object files to link (`objects1.rsp`). If I remove the BOM, it works OK.
I guess this has to do with the fix of cmake/cmake#21792.3.21.5Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23122regression: 3.22 does not pass -std=c++14 to nvcc2022-01-24T12:37:56-05:00Harmen Stoppelsregression: 3.22 does not pass -std=c++14 to nvccIn both `3.22.0` and `3.22.20220119-g58804d1` cmake fails to pass `-std=c++14` to `nvcc` when using clang 11 as host cxx compiler.
CMakeLists.txt
```cmake
cmake_minimum_required(VERSION 3.18)
project(std_cuda CXX CUDA)
set(CMAKE_CXX_STA...In both `3.22.0` and `3.22.20220119-g58804d1` cmake fails to pass `-std=c++14` to `nvcc` when using clang 11 as host cxx compiler.
CMakeLists.txt
```cmake
cmake_minimum_required(VERSION 3.18)
project(std_cuda CXX CUDA)
set(CMAKE_CXX_STANDARD 14)
add_library(std_cuda a.cu)
```
a.cu
```cuda
#include <type_traits>
```
Current behavior
```
$ /path/to/cmake-master/bin/cmake .. -DCMAKE_CUDA_HOST_COMPILER=/usr/bin/clang++-10 -DCMAKE_CXX_COMPILER=/usr/bin/clang++-10 -DCMAKE_VERBOSE_MAKEFILE=1 >& /dev/null && make | grep nvcc
/path/to/bin/nvcc -forward-unknown-to-host-compiler -ccbin=/usr/bin/clang++-10 --generate-code=arch=compute_52,code=[compute_52,sm_52] -MD -MT CMakeFiles/std_cuda.dir/a.cu.o -MF CMakeFiles/std_cuda.dir/a.cu.o.d -x cu -c /tmp/tmp.w1RusGPDTz/a.cu -o CMakeFiles/std_cuda.dir/a.cu.o
/usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/type_traits:588:162: error: type-id cannot have a name
template< class _Tp> using __is_signed_integer = __is_one_of< __remove_cv_t< _Tp> , signed char, signed short, signed int, signed long, signed long long, signed __int128_t> ;
^
1 error generated.
```
On older versions of CMake:
```
$ /path/to/cmake-3.21.4/bin/cmake .. -DCMAKE_CUDA_HOST_COMPILER=/usr/bin/clang++-10 -DCMAKE_CXX_COMPILER=/usr/bin/clang++-10 -DCMAKE_VERBOSE_MAKEFILE=1 >& /dev/null && make | grep nvcc
/path/to/bin/nvcc -forward-unknown-to-host-compiler -ccbin=/usr/bin/clang++-10 --generate-code=arch=compute_52,code=[compute_52,sm_52] -std=c++14 -MD -MT CMakeFiles/std_cuda.dir/a.cu.o -MF CMakeFiles/std_cuda.dir/a.cu.o.d -x cu -c /tmp/tmp.w1RusGPDTz/a.cu -o CMakeFiles/std_cuda.dir/a.cu.o
```
If no flag is passed, the default `-std=gnu++14` is used when nvcc invokes clang, which apparently is incompatible thanks to the __int128_t extension.
Note that when I set `set(CMAKE_CXX_STANDARD 17)`, `-std=c++17` is passed to nvcc, likely because `CMAKE_CUDA_STANDARD_COMPUTED_DEFAULT "14"` is default.3.22.2Raul Tambreraul@tambre.eeRaul Tambreraul@tambre.eehttps://gitlab.kitware.com/cmake/cmake/-/issues/23074CPack failing for MinGW builds since 3.222022-01-12T12:10:35-05:00Derek ChanCPack failing for MinGW builds since 3.22Hello,
Our project has the MinGW packaging failing since cmake v3.22.0. It is working fine up to v3.21.4.
It uses CPack with `CPACK_GENERATOR=ZIP`. This is a cross-build running on Linux targeting Windows. Compilation and linking work ...Hello,
Our project has the MinGW packaging failing since cmake v3.22.0. It is working fine up to v3.21.4.
It uses CPack with `CPACK_GENERATOR=ZIP`. This is a cross-build running on Linux targeting Windows. Compilation and linking work fine, but the packaging step fails at `fixup_bundle` in BundleUtilities. The packaging fails only for the MinGW build.
Using cmake v3.22 we are getting errors like these:
```
CPack: Install projects
CPack: - Run preinstall target for: ja2-stracciatella
CPack: - Install project: ja2-stracciatella []
CMake Error at /usr/local/share/cmake-3.22/Modules/BundleUtilities.cmake:471 (file):
file READ_ELF given FILE
"/home/runner/work/ja2-stracciatella/ja2-stracciatella/ci-build/_CPack_Packages/win64/ZIP/ja2-stracciatella_0.19.0-git+f7dfca6_win-mingw64-cross/ja2.exe"
that is not a valid ELF file.
Call Stack (most recent call first):
/usr/local/share/cmake-3.22/Modules/BundleUtilities.cmake:527 (get_item_rpaths)
/usr/local/share/cmake-3.22/Modules/BundleUtilities.cmake:593 (set_bundle_key_values)
/usr/local/share/cmake-3.22/Modules/BundleUtilities.cmake:934 (get_bundle_keys)
/home/runner/work/ja2-stracciatella/ja2-stracciatella/ci-build/install-dlls-mingw.cmake:104 (fixup_bundle)
/home/runner/work/ja2-stracciatella/ja2-stracciatella/ci-build/cmake_install.cmake:89 (include)
CMake Error at /usr/local/share/cmake-3.22/Modules/BundleUtilities.cmake:471 (file):
...
```
The project's build config can be found [here](https://github.com/ja2-stracciatella/ja2-stracciatella/blob/master/CMakeLists.txt) and also [here](https://github.com/ja2-stracciatella/ja2-stracciatella/tree/master/cmake) on GitHub. The packaging works with the exact same config using cmake v3.21.4 (and earlier).
An example of a failed build can be seen [here](https://github.com/ja2-stracciatella/ja2-stracciatella/runs/4696399666). A successful build with cmake v3.21 is [here](https://github.com/ja2-stracciatella/ja2-stracciatella/runs/4696899519).
I understand this might not be enough information to pin down the problem, but I do not know much about CMake and I am lost at how to investigate further. I don't see anything suspicious in v3.22 release notes.
Any pointers or help is appreciated. Thank you!3.22.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23018FindGLUT: cmake 3.22.1 with PkgConf no longer sets GLUT_INCLUDE_DIR2022-03-30T16:23:06-04:00Evan BarentinFindGLUT: cmake 3.22.1 with PkgConf no longer sets GLUT_INCLUDE_DIRHi,
Since last cmake release on Archlinux, and I believe [this merge request](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6251) which introduced pkgconf usage in `FindGLUT.cmake`, `GLUT_INCLUDE_DIR` and `GLUT_glut_LIBRARY` ...Hi,
Since last cmake release on Archlinux, and I believe [this merge request](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/6251) which introduced pkgconf usage in `FindGLUT.cmake`, `GLUT_INCLUDE_DIR` and `GLUT_glut_LIBRARY` are no longer set when pkgconf is found.
Instead, a `GLUT_INCLUDEDIR` is created and the path to `glut.so` can be found in `GLUT_LINK_LIBRARIES`.
Maybe the behaviour is wanted and the documentation just needs a small update ?
You can find attached a small Dockerfile and a basic CMakeLists.txt to play with.
[Dockerfile](/uploads/6ecbbdcecef438e13a222e7726092f75/Dockerfile)
[CMakeLists.txt](/uploads/79a60343a0ea0c13855d59aaca989895/CMakeLists.txt)
---
This are all the variables related to GLUT in the `CMakeCache.txt`
<details>
```txt
GLUT_CFLAGS:INTERNAL=
GLUT_CFLAGS_I:INTERNAL=
GLUT_CFLAGS_OTHER:INTERNAL=
GLUT_FOUND:INTERNAL=1
GLUT_INCLUDEDIR:INTERNAL=/usr/include
GLUT_INCLUDE_DIRS:INTERNAL=
GLUT_LDFLAGS:INTERNAL=-L/usr/lib;-lglut
GLUT_LDFLAGS_OTHER:INTERNAL=
GLUT_LIBDIR:INTERNAL=/usr/lib
GLUT_LIBRARIES:INTERNAL=glut
GLUT_LIBRARY_DIRS:INTERNAL=/usr/lib
GLUT_LIBS:INTERNAL=
GLUT_LIBS_L:INTERNAL=
GLUT_LIBS_OTHER:INTERNAL=
GLUT_LIBS_PATHS:INTERNAL=
GLUT_MODULE_NAME:INTERNAL=glut
GLUT_PREFIX:INTERNAL=/usr
GLUT_STATIC_CFLAGS:INTERNAL=
GLUT_STATIC_CFLAGS_I:INTERNAL=
GLUT_STATIC_CFLAGS_OTHER:INTERNAL=
GLUT_STATIC_INCLUDE_DIRS:INTERNAL=
GLUT_STATIC_LDFLAGS:INTERNAL=-L/usr/lib;-lglut;-lX11;-lXxf86vm;-lXrandr;-lGL;-lm
GLUT_STATIC_LDFLAGS_OTHER:INTERNAL=
GLUT_STATIC_LIBDIR:INTERNAL=
GLUT_STATIC_LIBRARIES:INTERNAL=glut;X11;Xxf86vm;Xrandr;GL;m
GLUT_STATIC_LIBRARY_DIRS:INTERNAL=/usr/lib
GLUT_STATIC_LIBS:INTERNAL=
GLUT_STATIC_LIBS_L:INTERNAL=
GLUT_STATIC_LIBS_OTHER:INTERNAL=
GLUT_STATIC_LIBS_PATHS:INTERNAL=
GLUT_VERSION:INTERNAL=3.2.1
GLUT_glut_INCLUDEDIR:INTERNAL=
GLUT_glut_LIBDIR:INTERNAL=
GLUT_glut_PREFIX:INTERNAL=
GLUT_glut_VERSION:INTERNAL=
```
</details>3.22.2Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22989Install file failed since upgrade cmake from 3.21.4 to 3.222021-12-07T10:37:29-05:00SandyInstall file failed since upgrade cmake from 3.21.4 to 3.22# With version 3.22.0:
```
cmake -DCMAKE_INSTALL_COMPONENT=cxx -D CMAKE_INSTALL_PREFIX=/libcxx/13.0.1-r0/build/projects/libcxx/src -P /libcxx/13.0.1-r0/build/projects/libcxx/cmake_install.cmake
-- Install configuration: "Debug"
-- Insta...# With version 3.22.0:
```
cmake -DCMAKE_INSTALL_COMPONENT=cxx -D CMAKE_INSTALL_PREFIX=/libcxx/13.0.1-r0/build/projects/libcxx/src -P /libcxx/13.0.1-r0/build/projects/libcxx/cmake_install.cmake
-- Install configuration: "Debug"
-- Installing: /libcxx/13.0.1-r0/build/projects/libcxx/src/lib64/libc++.so.1.0
-- Installing: /libcxx/13.0.1-r0/build/projects/libcxx/src/lib64/libc++.so.1
-- Set runtime path of "/libcxx/13.0.1-r0/build/projects/libcxx/src/lib64/libc++.so.1.0" to ""
-- Installing: /libcxx/13.0.1-r0/build/projects/libcxx/src/lib64/libc++.so
CMake Error at cmake_install.cmake:88 (file):
file RPATH_CHANGE could not write new RPATH:
to the file:
/libcxx/13.0.1-r0/build/projects/libcxx/src/lib64/libc++.so
Call Stack (most recent call first):
/libcxx/13.0.1-r0/build/projects/libcxx/cmake_install.cmake:56 (include)
```
# With cmake 3.21.4
```
cmake -DCMAKE_INSTALL_COMPONENT=cxx -D CMAKE_INSTALL_PREFIX=/libcxx/13.0.1-r0/build/projects/libcxx/src -P /libcxx/13.0.1-r0/build/projects/libcxx/cmake_install.cmake^C
cli10@pek-lpg-core2:/libcxx/13.0.1-r0/build/projects/libcxx/src$ cmake -DCMAKE_INSTALL_COMPONENT=cxx -D CMAKE_INSTALL_PREFIX=/libcxx/13.0.1-r0/build/projects/libcxx/src -P /libcxx/13.0.1-r0/build/projects/libcxx/cmake_install.cmake
-- Install configuration: "Debug"
-- Up-to-date: /libcxx/13.0.1-r0/build/projects/libcxx/src/lib64/libc++.so.1.0
-- Up-to-date: /libcxx/13.0.1-r0/build/projects/libcxx/src/lib64/libc++.so.1
-- Up-to-date: /libcxx/13.0.1-r0/build/projects/libcxx/src/lib64/libc++.so
-- Installing: /libcxx/13.0.1-r0/build/projects/libcxx/src/lib64/libc++.a
-- Installing: /libcxx/13.0.1-r0/build/projects/libcxx/src/lib64/libc++experimental.a
```
# Part of CMakeList.txt
```
install(FILES "${LIBCXX_LIBRARY_DIR}/libc++${CMAKE_SHARED_LIBRARY_SUFFIX}" //this is libc++.so
DESTINATION ${LIBCXX_INSTALL_LIBRARY_DIR}
COMPONENT libcxx)
```
# Part of the cmake_install.cmake
```
[snip]
file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/lib64" TYPE SHARED_LIBRARY FILES "/libcxx/13.0.1-r0/build/lib64/libc++.so")
if(EXISTS "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib64/libc++.so" AND
NOT IS_SYMLINK "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib64/libc++.so")
file(RPATH_CHANGE
FILE "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib64/libc++.so"
OLD_RPATH "\$ORIGIN:"
NEW_RPATH "")
if(CMAKE_INSTALL_DO_STRIP)
execute_process(COMMAND "/libcxx/13.0.1-r0/recipe-sysroot-native/usr/bin/llvm-strip" "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib64/libc++.so")
endif()
endif()
[snip]
```
# Part of build.ninja
```
[snip]
#############################################
# Create library symlink lib64/libc++.so
build lib64/libc++.so.1 lib64/libc++.so: CMAKE_SYMLINK_LIBRARY lib64/libc++.so.1.0
POST_BUILD = cd /libcxx/13.0.1-r0/build/projects/libcxx/src && /libcxx/13.0.1-r0/recipe-sysroot-native/usr/bin/cmake -E remove /libcxx/13.0.1-r0/build/lib64/libc++.so && /libcxx/13.0.1-r0/recipe-sysroot-native/usr/bin/cmake -E echo "INPUT(libc++.so.1 -lc++abi)" > /libcxx/13.0.1-r0/build/lib64/libc++.so
[snip]
```
Here is libc++.so
libc++.so
$file libc++.so
libc++.so: ASCII text
$ cat libc++.so
INPUT(libc++.so.1 -lc++abi)
# Question
I noticed that there is some changes related to "bool cmSystemTools::ChangeRPath" in cmake 3.22.0 , maybe it is related to that change.
As I understand, libc++.so is just "ASCII text", so it should not have RPATH. BUT, seems new cmake still try to find it
and change it. so error occurred.3.22.1https://gitlab.kitware.com/cmake/cmake/-/issues/22976FindPkgConfig: CMake 3.22.0 finds pkgconf instead of pkg-config2021-12-03T08:53:30-05:00Julien-Blanc-tgcmFindPkgConfig: CMake 3.22.0 finds pkgconf instead of pkg-configWe have a setup (basically, buildroot) where pkg-config is a wrapper around pkgconf, calling it with correct environment variables set.
Since cmake 3.22, FindPkgConfig also searches for a pkgconf executable (see 94a84dc0af227e574e2a9950...We have a setup (basically, buildroot) where pkg-config is a wrapper around pkgconf, calling it with correct environment variables set.
Since cmake 3.22, FindPkgConfig also searches for a pkgconf executable (see 94a84dc0af227e574e2a9950cf2c830e2f57218f) . This breaks this setup, as now cmake finds the pkgconf executable instead of the pkg-config one.
The patch should be fixed to:
- {- list(PREPEND PKG_CONFIG_NAMES "pkgconf") -}
- {+ list(APPEND PKG_CONFIG_NAMES "pkgconf") +}
Which prefer pkg-config over pkgconf if both are present, to avoid breaking existing setups.3.22.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22964add_custom_command: cmake 3.22.0 does not run all custom commands in VS manag...2021-12-03T08:59:23-05:00Haraldadd_custom_command: cmake 3.22.0 does not run all custom commands in VS managed projectsThe description, and reproducible use case, can be found here:
https://github.com/cross-language-cpp/djinni-support-lib/issues/70
We wonder, is there a new behavior in cmake we should be aware about
or,
is this a bug in cmake we should ...The description, and reproducible use case, can be found here:
https://github.com/cross-language-cpp/djinni-support-lib/issues/70
We wonder, is there a new behavior in cmake we should be aware about
or,
is this a bug in cmake we should ignore and just use a different version3.22.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22963RPATH_CHANGE fails when shared object is a GNU ld script2023-09-19T16:05:32-04:00Arcadiy IvanovRPATH_CHANGE fails when shared object is a GNU ld scriptFrom LLVM build:
```cmake
if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xcxxx" OR NOT CMAKE_INSTALL_COMPONENT)
if(EXISTS "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libc++.so" AND
NOT IS_SYMLINK "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/...From LLVM build:
```cmake
if("x${CMAKE_INSTALL_COMPONENT}x" STREQUAL "xcxxx" OR NOT CMAKE_INSTALL_COMPONENT)
if(EXISTS "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libc++.so" AND
NOT IS_SYMLINK "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libc++.so")
file(RPATH_CHECK
FILE "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libc++.so"
RPATH "")
endif()
file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/lib" TYPE SHARED_LIBRARY FILES "/home/user/llvm/llvm.stage1.build/lib/libc++.so")
if(EXISTS "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libc++.so" AND
NOT IS_SYMLINK "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libc++.so")
file(RPATH_CHANGE
FILE "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libc++.so"
OLD_RPATH "/home/user/llvm/llvm.stage1.build/lib:"
NEW_RPATH "")
if(CMAKE_INSTALL_DO_STRIP)
execute_process(COMMAND "/usr/bin/strip" "$ENV{DESTDIR}${CMAKE_INSTALL_PREFIX}/lib/libc++.so")
endif()
endif()
endif()
```
```bash
-- Installing: /home/user/llvm/llvm.stage1.bin/lib/libc++.so
CMake Error at projects/libcxx/src/cmake_install.cmake:88 (file):
file RPATH_CHANGE could not write new RPATH:
to the file:
/home/user/llvm/llvm.stage1.bin/lib/libc++.so
Call Stack (most recent call first):
projects/libcxx/cmake_install.cmake:56 (include)
projects/cmake_install.cmake:49 (include)
cmake_install.cmake:76 (include)
FAILED: CMakeFiles/install.util
cd /home/user/llvm/llvm.stage1.build && /usr/bin/cmake -P cmake_install.cmake
```
```bash
$ cat llvm.stage1.bin/lib/libc++.so
INPUT(libc++.so.1 -lc++abi)
```3.22.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22962GNUInstallDirs: CMake 3.22 broken on 64-bit RedHat platforms: forces lib/ ins...2021-12-01T09:34:37-05:00Christopher "Monty" MontgomeryGNUInstallDirs: CMake 3.22 broken on 64-bit RedHat platforms: forces lib/ instead of lib64/ecaca8c129ea8f1f772823d221760fc103a32c28 from !6512 broke builds on RedHat platforms.
The problem has a few interacting components, some of which preexist the visible breakage:
1) RH dev and build machines normally have the 'conda' bui...ecaca8c129ea8f1f772823d221760fc103a32c28 from !6512 broke builds on RedHat platforms.
The problem has a few interacting components, some of which preexist the visible breakage:
1) RH dev and build machines normally have the 'conda' build environment installed and set up for use. That means the various CONDA_XXX environment vars are always present in the shell environment, even on containerized 'clean' builds, whether building in the conda environment or not. This has ~always been the case AFAIK.
2) CMake has always treated the mere presence of the ENV{CONDA_XXXX} vars as indicating we're building with conda, whether we are or not. This is pre-existing breakage, and __system_type_for_install gets set to "conda" in GNUInstallDirs.cmake. Although CMkae has always made this error, it has not been visible until...
3) ecaca8c129ea8f1f772823d221760fc103a32c28 changed:
```
diff --git a/Modules/GNUInstallDirs.cmake b/Modules/GNUInstallDirs.cmake
index ead55ca1d8..1b9cfce258 100644
--- a/Modules/GNUInstallDirs.cmake
+++ b/Modules/GNUInstallDirs.cmake
[...]
@@ -251,7 +277,8 @@
set(__LAST_LIBDIR_DEFAULT "lib/${CMAKE_LIBRARY_ARCHITECTURE}")
endif()
endif()
- else() # not debian, rely on CMAKE_SIZEOF_VOID_P:
+ elseif(NOT DEFINED __system_type_for_install)
+ # not debian, alpine, arch, or conda so rely on CMAKE_SIZEOF_VOID_P:
if("${CMAKE_SIZEOF_VOID_P}" EQUAL "8")
set(_LIBDIR_DEFAULT "lib64")
if(DEFINED _GNUInstallDirs_LAST_CMAKE_INSTALL_PREFIX)
```
Now instead of getting lib64 if 'not debian', we get lib64 only if __system_type_for_install is unset, but it's set to the misidentified 'conda'. So CMake tries to install to lib/ on 64-bit RedHat distros.
Note that the other 'improvement' of checking to see if the conda install dir exist is uninvolved (and neither helps nor hurts) here; it's set by the system to '/usr'
Obviously, the best course is to fix conda detection, but given that it was always broken on RH, perhaps temporarily rolling back the change for now is sufficient if fixing conda detect is tricky.3.22.1https://gitlab.kitware.com/cmake/cmake/-/issues/22942CMake fails to detect xlC 16 via CMakeCCompilerId.c2021-11-29T12:27:41-05:00Bret Brownbbrown105@bloomberg.netCMake fails to detect xlC 16 via CMakeCCompilerId.cSpecifically, xlC needs to be wrapped or linked such that the compiler basename is `cc` and exists on `PATH` so that (I'm assuming) the toolchain detection routines kick in.
The reproduction works like so:
```
$ cat source/CMakeLists.t...Specifically, xlC needs to be wrapped or linked such that the compiler basename is `cc` and exists on `PATH` so that (I'm assuming) the toolchain detection routines kick in.
The reproduction works like so:
```
$ cat source/CMakeLists.txt
cmake_minimum_required(VERSION 3.21)
project(test C)
add_executable(test test.c)
$ which cc
/tmp/tmp.MGA9IsdGVH/cc
$ cmake --version
cmake version 3.22.0
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ cmake -S source -B build
CMake Error at /path/to/share/cmake-3.22/Modules/CMakeTestCCompiler.cmake:69 (message):
The C compiler
"/tmp/tmp.MGA9IsdGVH/cc"
is not able to compile a simple test program.
...snip...
Linking C executable cmTC_466c9
/path/to/bin/cmake -E cmake_link_script CMakeFiles/cmTC_466c9.dir/link.txt --verbose=1
/tmp/tmp.MGA9IsdGVH/cc CMakeFiles/cmTC_466c9.dir/testCCompiler.c.o -o cmTC_466c9 /usr/lib /lib
ld: 0711-168 SEVERE ERROR: Input file: /usr/lib
Input files must be regular files.
gmake[1]: *** [CMakeFiles/cmTC_466c9.dir/build.make:99: cmTC_466c9] Error 12
```
Note that the above works fine with CMake 3.21. Relevant CMake configure logs:
```
-- The C compiler identification is XL 16.1.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /tmp/tmp.MGA9IsdGVH/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
```
A viable workaround using CMake 3.22 is to explicitly set `CMAKE_CXX_COMPILER` equal to something with the basename `xlC`.3.22.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/229393.22 regression: Crash with 32bit clang + mingw + TIMESTAMP2021-12-01T09:33:28-05:00Christoph Reiter3.22 regression: Crash with 32bit clang + mingw + TIMESTAMPDownstream issue: https://github.com/msys2/MINGW-packages/issues/10152
Starting with 3.22 (3.21.4 works) the following crashes:
CMakeLists.txt:
```
string(TIMESTAMP DEFAULT_BUILD "%Y%m%d")
```
```
$ cmake -GNinja .
-- Building for: N...Downstream issue: https://github.com/msys2/MINGW-packages/issues/10152
Starting with 3.22 (3.21.4 works) the following crashes:
CMakeLists.txt:
```
string(TIMESTAMP DEFAULT_BUILD "%Y%m%d")
```
```
$ cmake -GNinja .
-- Building for: Ninja
CMake Warning (dev) in CMakeLists.txt:
No project() command is present. The top-level CMakeLists.txt file must
contain a literal, direct call to the project() command. Add a line of
code such as
project(ProjectName)
near the top of the file, but after cmake_minimum_required().
CMake is pretending there is a "project(Project)" command on the first
line.
This warning is for project developers. Use -Wno-dev to suppress it.
-- The C compiler identification is Clang 13.0.0
-- The CXX compiler identification is Clang 13.0.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/msys64/clang32/bin/cc.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:/msys64/clang32/bin/c++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX comp
Segmentation fault
```
```
Thread 1 received signal SIGSEGV, Segmentation fault.
0x010eea42 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__set_short_size (this=0x10, __s=4) at C:/msys64/clang32/include/c++/v1/string:1500
1500 {__r_.first().__s.__size_ = (unsigned char)(__s << 1);}
(gdb) bt
#0 0x010eea42 in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__set_short_size (this=0x10, __s=4)
at C:/msys64/clang32/include/c++/v1/string:1500
#1 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__init (this=0x10, __s=0x93e9d0 "@▒D\v@▒D\v\b▒", __sz=4)
at C:/msys64/clang32/include/c++/v1/string:1882
#2 std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string (this=0x10, __s=0x93e9d0 "@▒D\v@▒D\v\b▒", __n=4)
at C:/msys64/clang32/include/c++/v1/string:1915
#3 cmTimestamp::AddTimestampComponent (this=0x93ec18, flag=89 'Y',
timeStruct=..., timeT=1637518452)
at /usr/src/debug/cmake-3.22.0/Source/cmTimestamp.cxx:217
#4 0x010ee6bf in cmTimestamp::CreateTimestampFromTimeT (this=0x93ec18,
timeT=<optimized out>, formatString=..., utcFlag=<optimized out>)
at /usr/src/debug/cmake-3.22.0/Source/cmTimestamp.cxx:98
#5 0x010ee3b4 in cmTimestamp::CurrentTime (this=0x93ec18, formatString=...,
utcFlag=<optimized out>)
at /usr/src/debug/cmake-3.22.0/Source/cmTimestamp.cxx:46
#6 0x0108adbf in (anonymous namespace)::HandleTimestampCommand (args=...,
status=...) at /usr/src/debug/cmake-3.22.0/Source/cmStringCommand.cxx:850
#7 0x0119c6ff in cmSubcommandTable::operator() (this=<optimized out>,
key=..., args=..., status=...)
at /usr/src/debug/cmake-3.22.0/Source/cmSubcommandTable.cxx:27
#8 0x0b458439 in ?? ()
Backtrace stopped: previous
```
-> https://gitlab.kitware.com/cmake/cmake/-/blob/55d0c88309c1fab0882b846085cdd5ddc6d9a105/Source/cmTimestamp.cxx#L2173.22.1