CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-11-23T17:58:52-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/21714FindPkgConfig: Add support for specifying a 'static' flavor of a target2023-11-23T17:58:52-05:00Jazu DevelopmentFindPkgConfig: Add support for specifying a 'static' flavor of a targetPlease check [this](https://discourse.cmake.org/t/link-shared-cmake-target-with-prebuilt-static-libraries-pic/2504/2) discourse thread for more details
Best regardsPlease check [this](https://discourse.cmake.org/t/link-shared-cmake-target-with-prebuilt-static-libraries-pic/2504/2) discourse thread for more details
Best regardshttps://gitlab.kitware.com/cmake/cmake/-/issues/25103MSVC: _CMAKE_INCLUDE_SYSTEM_FLAG_${lang}_WARNING should be configurable from ...2024-01-31T16:27:09-05:00Patrick H.MSVC: _CMAKE_INCLUDE_SYSTEM_FLAG_${lang}_WARNING should be configurable from outsideHello!
would it be possible to make this option externally configurable instead of hard coding it to "-external:W0". Currently it has the _ prefix which means it should be a private variable and is not really documented. So changing it t...Hello!
would it be possible to make this option externally configurable instead of hard coding it to "-external:W0". Currently it has the _ prefix which means it should be a private variable and is not really documented. So changing it this way I have a bit of a bad feeling.
For background, we have a larger C++ project that runs on multiple platforms (Windows, macOS, Linux, cell phones). We collect our dependencies through Conan, which accounts for internal libraries and third-party libraries. Currently, all are marked as external and therefore get an /external:W0, which is suboptimal. The default value when enabling system includes via compile flags is currently even W1. Some of our problems would be solved by enabling NO_SYSTEM_FROM_IMPORTED, but depending on the build configuration, other stuff is also flagged as system. So I would like to avoid passing W0 there.
Another problem is that /W0 also deactivates parts of /SDL e.g. the warnings as error for security relevant compile checks.
See https://learn.microsoft.com/en-us/cpp/build/reference/sdl-enable-additional-security-checks?view=msvc-170
The default could still be W0, but this would make things more flexible for everyone.
Best,
Patrickhttps://gitlab.kitware.com/cmake/cmake/-/issues/23640IPO: Add option to specify number of parallel LTRANS jobs2022-08-15T10:48:36-04:00Linus Dierheimerlinus@dierheimer.deIPO: Add option to specify number of parallel LTRANS jobsCurrently, when using `INTERPROCEDURAL_OPTIMIZATION`, cmake adds `-flto ...` to the c flags.
Since GCC 12.1, this results in a warning:
```
lto-wrapper: warning: using serial compilation of <number of jobs> LTRANS jobs
lto-wrapper: note...Currently, when using `INTERPROCEDURAL_OPTIMIZATION`, cmake adds `-flto ...` to the c flags.
Since GCC 12.1, this results in a warning:
```
lto-wrapper: warning: using serial compilation of <number of jobs> LTRANS jobs
lto-wrapper: note: see the ‘-flto’ option documentation for more information
```
It expects `-flto` to take a number of jobs it should compile in parallel, e.g `-flto=8`, `-flto=1`, etc.
There is also the option of `-flto=auto`, which seems to be the same as `-flto=$(nproc)`
Currently it seems to fall back to 1 parallel job.
I suggest to append `auto` as default value, and give an option to manually overwrite it, e.g.:
```
set(CMAKE_INTERPROCEDURAL_OPTIMIZATION_JOBS 8)
```
If `auto` is not practicable as default, at least append `1` to disable the warnings.https://gitlab.kitware.com/cmake/cmake/-/issues/21445CPack/DEB: Support creating multiarch Debian packages2022-06-09T14:23:27-04:00Ben BoeckelCPack/DEB: Support creating multiarch Debian packagesCPack's Debian package generator does not appear to support multi-arch today. See [this Discourse thread](https://discourse.cmake.org/t/cpack-debian-multi-arch-control-file-tag/1753).CPack's Debian package generator does not appear to support multi-arch today. See [this Discourse thread](https://discourse.cmake.org/t/cpack-debian-multi-arch-control-file-tag/1753).https://gitlab.kitware.com/cmake/cmake/-/issues/25530macOS: compiler option '-macosx-version-min' has been renamed to '-macos-vers...2024-01-08T11:38:46-05:00Daniel FrankemacOS: compiler option '-macosx-version-min' has been renamed to '-macos-version-min'After update to macOS 14.2.1 and "Xcode 15.1 (15C65)", I now get the following warning when linking:
> compiler option '-macosx_version_min' has been renamed to '-macos_version_min'
My current cmake version is 3.23.5, but the documentat...After update to macOS 14.2.1 and "Xcode 15.1 (15C65)", I now get the following warning when linking:
> compiler option '-macosx_version_min' has been renamed to '-macos_version_min'
My current cmake version is 3.23.5, but the documentation of CMAKE_OSX_DEPLOYMENT_TARGET did not change between 3.23 and 3.28.1 (it still mentions "macosx-version-min"), hence I believe that the problem should still exist with the latest version.https://gitlab.kitware.com/cmake/cmake/-/issues/25522file(DOWNLOAD) error with macOS system curl2024-01-08T02:37:27-05:00Harry Mallonfile(DOWNLOAD) error with macOS system curlThis issue turned up in the past few weeks, I think it is related to a macOS update. I have a CMake thing which ends up requesting the same URL twice (with file(DOWNLOAD) and TLS_VERIFY=ON) and the second time I always get an SSL error (...This issue turned up in the past few weeks, I think it is related to a macOS update. I have a CMake thing which ends up requesting the same URL twice (with file(DOWNLOAD) and TLS_VERIFY=ON) and the second time I always get an SSL error (rather than a 404 as expected).
* I am on macOS 14.2 (23C64)
* curl from brew fails, curl built from source succeeds, curl from source with --system-curl fails
```
% otool -L ./bin/cmake
./bin/cmake:
/usr/lib/libcurl.4.dylib (compatibility version 7.0.0, current version 9.0.0)
/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.8)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 2202.0.0)
/System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 1226.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1600.157.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
```
This issue can be reproduced with
```
cmake_minimum_required(VERSION 3.15)
message(STATUS "TRY 1")
file(DOWNLOAD "https://raw.githubusercontent.com/cpp-pm/hunter-cache/master/8fd7dea/GTest/1.14.0/2b28c2a/297e0ef/4830b34/e5fa44f/basic-deps.DONE" "${CMAKE_CURRENT_BINARY_DIR}/basic-deps.DONE" TLS_VERIFY ON STATUS status LOG log)
message("STATUS: ${status}")
message("LOG: ${log}")
message(STATUS "TRY 2")
file(DOWNLOAD "https://raw.githubusercontent.com/cpp-pm/hunter-cache/master/8fd7dea/GTest/1.14.0/2b28c2a/297e0ef/4830b34/e5fa44f/basic-deps.DONE" "${CMAKE_CURRENT_BINARY_DIR}/basic-deps.DONE.2" TLS_VERIFY ON STATUS status LOG log)
message("STATUS: ${status}")
message("LOG: ${log}")
```
Correct behaviour is to get a 404 each time, incorrect is that the second request gets
```
STATUS: 35;"SSL connect error"
LOG: Trying 185.199.111.133:443...
Connected to raw.githubusercontent.com (185.199.111.133) port 443
ALPN: curl offers h2,http/1.1
(304) (OUT), TLS handshake, Client hello (1):
[330 bytes data]
CAfile: /etc/ssl/cert.pem
CApath: none
(304) (IN), TLS handshake, Server hello (2):
[122 bytes data]
(304) (IN), TLS handshake, Unknown (8):
[19 bytes data]
(304) (IN), TLS handshake, Certificate (11):
[3050 bytes data]
LibreSSL/3.3.6: error:0DFFF0A1:lib(13):func(4095):reason(161)
Closing connection
```https://gitlab.kitware.com/cmake/cmake/-/issues/25192VS: Minor toolset version selection breaks for toolset 14.36 and above2023-08-21T09:25:58-04:00gerard-ryan-immersaviewVS: Minor toolset version selection breaks for toolset 14.36 and aboveEDIT: This is caused by [VS Developer Community feedback item 10385615](https://developercommunity.visualstudio.com/t/MicrosoftVCToolsVersion1436176prop/10385615)
# Reproduction
* CMake 3.27.1
* Visual Studio Professional 2022 17.7.1
`...EDIT: This is caused by [VS Developer Community feedback item 10385615](https://developercommunity.visualstudio.com/t/MicrosoftVCToolsVersion1436176prop/10385615)
# Reproduction
* CMake 3.27.1
* Visual Studio Professional 2022 17.7.1
`CMakeLists.txt`
```cmake
cmake_minimum_required(VERSION 3.27.1)
project(minimal)
```
```shell
$ cmake -T "version=14.37.32822" -B ./build/ -S ./
-- Selecting Windows SDK version 10.0.22621.0 to target Windows 10.0.19045.
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
CMake Error at CMakeLists.txt:2 (project):
No CMAKE_C_COMPILER could be found.
CMake Error at CMakeLists.txt:2 (project):
No CMAKE_CXX_COMPILER could be found.
-- Configuring incomplete, errors occurred!
```
# Investigation
Looking into this further I found the issue seemed to be related to events like the following in `CMakeConfigureLog.yaml`
```yaml
---
events:
-
kind: "message-v1"
backtrace:
- "C:/Program Files/CMake/share/cmake-3.27/Modules/CMakeDetermineSystem.cmake:211 (message)"
- "CMakeLists.txt:2 (project)"
message: |
The system is: Windows - 10.0.19045 - AMD64
-
kind: "message-v1"
backtrace:
- "C:/Program Files/CMake/share/cmake-3.27/Modules/CMakeDetermineCompilerId.cmake:17 (message)"
- "C:/Program Files/CMake/share/cmake-3.27/Modules/CMakeDetermineCompilerId.cmake:64 (__determine_compiler_id_test)"
- "C:/Program Files/CMake/share/cmake-3.27/Modules/CMakeDetermineCCompiler.cmake:123 (CMAKE_DETERMINE_COMPILER_ID)"
- "CMakeLists.txt:2 (project)"
message: |
Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler:
Build flags:
Id flags:
The output was:
1
MSBuild version 17.7.2+d6990bcfa for .NET Framework
Build started 17/08/2023 12:47:15 PM.
Project "C:\\Users\\gerard\\Desktop\\temp\\build\\CMakeFiles\\3.27.1\\CompilerIdC\\CompilerIdC.vcxproj" on node 1 (default targets).
C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\VC\\Auxiliary\\Build\\14.37.17.7\\Microsoft.VCToolsVersion.14.37.17.7.props(3,3): error MSB4019: The imported project "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\VC\\Auxiliary\\Build\\14.37.17.7\\Microsoft.VCRedistVersion.default.props" was not found. Confirm that the expression in the Import declaration "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\VC\\Auxiliary\\Build\\14.37.17.7\\Microsoft.VCRedistVersion.default.props" is correct, and that the file exists on disk. [C:\\Users\\gerard\\Desktop\\temp\\build\\CMakeFiles\\3.27.1\\CompilerIdC\\CompilerIdC.vcxproj]
Done Building Project "C:\\Users\\gerard\\Desktop\\temp\\build\\CMakeFiles\\3.27.1\\CompilerIdC\\CompilerIdC.vcxproj" (default targets) -- FAILED.
Build FAILED.
"C:\\Users\\gerard\\Desktop\\temp\\build\\CMakeFiles\\3.27.1\\CompilerIdC\\CompilerIdC.vcxproj" (default target) (1) ->
C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\VC\\Auxiliary\\Build\\14.37.17.7\\Microsoft.VCToolsVersion.14.37.17.7.props(3,3): error MSB4019: The imported project "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\VC\\Auxiliary\\Build\\14.37.17.7\\Microsoft.VCRedistVersion.default.props" was not found. Confirm that the expression in the Import declaration "C:\\Program Files\\Microsoft Visual Studio\\2022\\Professional\\VC\\Auxiliary\\Build\\14.37.17.7\\Microsoft.VCRedistVersion.default.props" is correct, and that the file exists on disk. [C:\\Users\\gerard\\Desktop\\temp\\build\\CMakeFiles\\3.27.1\\CompilerIdC\\CompilerIdC.vcxproj]
0 Warning(s)
1 Error(s)
Time Elapsed 00:00:00.04
```
`C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Auxiliary\Build\14.37.17.7\Microsoft.VCToolsVersion.14.37.17.7.props` contains the following
```xml
<?xml version = "1.0" encoding="utf-8"?>
<Project ToolsVersion = "4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$([System.IO.Path]::GetFullPath($(MSBuildThisFileDirectory)Microsoft.VCRedistVersion.default.props))"/>
<PropertyGroup>
<VCToolsVersion Condition = "'$(VCToolsVersion)' == ''" >14.37.32822</VCToolsVersion>
</PropertyGroup>
</Project>
```
and as expected `C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Auxiliary\Build\14.37.17.7\` doesn't have a `Microsoft.VCRedistVersion.default.props`
The only `Microsoft.VCRedistVersion.default.props` I found was at `C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Auxiliary\Build\Microsoft.VCRedistVersion.default.props` with the following
```xml
<?xml version = "1.0" encoding="utf-8"?>
<Project ToolsVersion = "4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<VCToolsRedistVersion Condition = "'$(VCToolsRedistVersion)' == ''" >14.36.32532</VCToolsRedistVersion>
</PropertyGroup>
</Project>
```
# Workaround
Modifying the relevant `Microsoft.VCToolsVersion.*.props` with the following
```diff
- <Import Project="$([System.IO.Path]::GetFullPath($(MSBuildThisFileDirectory)Microsoft.VCRedistVersion.default.props))"/>
+ <Import Project="$([System.IO.Path]::GetFullPath($(MSBuildThisFileDirectory)/../Microsoft.VCRedistVersion.default.props))"/>
```
But as you can imagine this isn't really an acceptable workaround.
# Summary
The `CompilerIdC.vcxproj` directory is malformed and can't import the necessary `.props`.
Skimming through [Side-by-side minor version MSVC toolsets in Visual Studio 2017](https://devblogs.microsoft.com/cppblog/side-by-side-minor-version-msvc-toolsets-in-visual-studio-2019/) It looks like the expectation is that the `Microsoft.VCToolsVersion.*.props` are supposed to be copied around and not used in place as `C:\Users\gerard\Desktop\temp\build\CMakeFiles\3.27.1\CompilerIdC\CompilerIdC.vcxproj` does currently.https://gitlab.kitware.com/cmake/cmake/-/issues/25175Help: HTML documentation search results poorly ordered by Sphinx 5.2.0+2024-03-18T16:21:06-04:00Brad KingHelp: HTML documentation search results poorly ordered by Sphinx 5.2.0+The ~~[CMake 3.27](https://cmake.org/cmake/help/v3.27/search.html)~~ (EDIT: any version) CMake documentation search page built with Sphinx 5.2.0+ orders results poorly for search terms matching index entries. All index entries are retur...The ~~[CMake 3.27](https://cmake.org/cmake/help/v3.27/search.html)~~ (EDIT: any version) CMake documentation search page built with Sphinx 5.2.0+ orders results poorly for search terms matching index entries. All index entries are returned with high scores, even non-main entries corresponding to arbitrary cross-references, thus obscuring more relevant results.
This was discovered by discussion [on discourse](https://discourse.cmake.org/t/8587).
EDIT: Now reported as [Sphinx Issue 11578](https://github.com/sphinx-doc/sphinx/issues/11578).https://gitlab.kitware.com/cmake/cmake/-/issues/25165file(GET_RUNTIME_DEPENDENCIES) can not resolve soft links on Windows2023-08-09T03:35:49-04:00DyatlovsGlowingRadSuitfile(GET_RUNTIME_DEPENDENCIES) can not resolve soft links on WindowsWe have attempted to resolve dependencies by creating soft links instead of copying them next to the executables.
In the process we have experienced that the solution worked fine in the build directory but during install, we received the...We have attempted to resolve dependencies by creating soft links instead of copying them next to the executables.
In the process we have experienced that the solution worked fine in the build directory but during install, we received the following error:
```
CMake Error at build/cmake_install.cmake:123 (file):
file INSTALL cannot find
"\??\C:\temp\playground\thirdparties\bin\some_function.dll": No error
```
You'll find an example project in the attachments [playground.zip](/uploads/d865b32fac598715629bc8237f541f76/playground.zip) and the main CmakeLists.txt is provided below:
```
cmake_minimum_required(VERSION 3.25)
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS ON)
project(DUMMY_PROJECT VERSION 1.0.0 DESCRIPTION "Demonstrate symlinks on Windows" LANGUAGES CXX)
set(CMAKE_CXX_STANDARD 17)
add_subdirectory("modules")
add_executable(DummyMain main.cpp)
target_link_libraries(DummyMain PUBLIC dummy_lib PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}/thirdparties/lib/some_function.lib")
target_include_directories(DummyMain PUBLIC "${CMAKE_CURRENT_SOURCE_DIR}/thirdparties/include")
# In this section only soft-links are created for dlls instead of copying them
# aside the executables
add_custom_command(TARGET DummyMain POST_BUILD
COMMAND ${CMAKE_COMMAND} -D OBJECT_DEPENDENCY_LIST="$<TARGET_RUNTIME_DLLS:DummyMain>" -D TARGET_DIR_FOR_DEP=$<TARGET_FILE_DIR:DummyMain> -P "${CMAKE_CURRENT_SOURCE_DIR}/cmake/soft_linker.cmake"
COMMENT "Running soft linker script for project dependencies"
COMMAND_EXPAND_LISTS
)
add_custom_command(TARGET DummyMain POST_BUILD
COMMAND ${CMAKE_COMMAND} -D OBJECT_DEPENDENCY_LIST="${CMAKE_CURRENT_SOURCE_DIR}/thirdparties/bin/some_function.dll" -D TARGET_DIR_FOR_DEP=$<TARGET_FILE_DIR:DummyMain> -P "${CMAKE_CURRENT_SOURCE_DIR}/cmake/soft_linker.cmake"
COMMENT "Running soft linker script for precompiled dependencies"
COMMAND_EXPAND_LISTS
)
# This is the command that results in the following error:
# CMake Error at build/cmake_install.cmake:123 (file):
# file INSTALL cannot find
# "\??\C:\temp\playground\thirdparties\bin\some_function.dll": No error.
install(TARGETS DummyMain
RUNTIME_DEPENDENCIES
PRE_EXCLUDE_REGEXES "^api-ms-win.*" "^ext-ms.*
POST_EXCLUDE_REGEXES "^/lib.*" "[Ss][Yy][Ss][Tt][Ee][Mm]32.*"
RUNTIME DESTINATION "bin")
```https://gitlab.kitware.com/cmake/cmake/-/issues/25156file(GET_RUNTIME_DEPENDENCIES) should understand glibc-hwcaps on Linux/glibc2023-11-25T09:18:48-05:00Thiago Macieirafile(GET_RUNTIME_DEPENDENCIES) should understand glibc-hwcaps on Linux/glibcI was made aware that `file(GET_RUNTIME_DEPENDENCIES)` is used for packaging software. It appears not to understand that certain file paths on glibc-based Linux contain additional, optimised libraries that are used by the dynamic linker ...I was made aware that `file(GET_RUNTIME_DEPENDENCIES)` is used for packaging software. It appears not to understand that certain file paths on glibc-based Linux contain additional, optimised libraries that are used by the dynamic linker at runtime if the CPU supports the necessary features. This feature was added to glibc 2.26 back in 2017. The CMake feature must be aware of this because:
* it MUST NOT deploy _only_ the optimised library, without the baseline present
* it SHOULD deploy all the additional libraries if they exist
The way this feature works is that the library in question installs multiple files in subdirs of `$LIBDIR` and the dynamic loader will find it. For example, for libpng16 on openSUSE Tumbleweed:
```
$ find /lib64/ -name libpng16.so.16 -ls
3822267 4 lrwxrwxrwx 1 root root 19 Jun 24 11:25 /lib64/glibc-hwcaps/x86-64-v3/libpng16.so.16 -> libpng16.so.16.40.0
3821671 4 lrwxrwxrwx 1 root root 19 Jun 24 11:22 /lib64/libpng16.so.16 -> libpng16.so.16.40.0
```
At runtime, the dynamic linker will choose one of the two based on internal heuristics. For an AVX2-enabled machine ("x86-64 version 3"), for an arbitrary application:
```
$ ldd app
linux-vdso.so.1 (0x00007ffcaed0f000)
libpng16.so.16 => /lib64/glibc-hwcaps/x86-64-v3/libpng16.so.16.40.0 (0x00007fa63734c000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa637107000)
libz.so.1 => /lib64/libz.so.1 (0x00007fa6370eb000)
libm.so.6 => /lib64/libm.so.6 (0x00007fa637004000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa6373c0000)
```
But if this application were built with CMake and were being packaged by it with the libpng16 dependency, the deployment:
* MUST include `/lib64/libpng16.so.16` -> `/lib64/libpng16.so.16.40.0`
* SHOULD include `/lib64/glibc-hwcaps/x86-64-v3/libpng16.so.16` -> `/lib64/glibc-hwcaps/x86-64-v3/libpng16.so.16.40.0`
(Unless the user chooses not to support older-than-v3 systems, but that's a feature request)
The hwcaps feature is listed by ldconfig:
```
$ ldconfig -v -N -X
/usr/local/lib64: (from /etc/ld.so.conf:1)
/usr/local/lib: (from /etc/ld.so.conf:2)
/lib: (from <builtin>:0)
/lib64: (from <builtin>:0)
bunch of libraries
/lib64/glibc-hwcaps/x86-64-v2: (hwcap: "x86-64-v2") (from <builtin>:0)
/lib64/glibc-hwcaps/x86-64-v3: (hwcap: "x86-64-v3") (from <builtin>:0)
libpng16.so.16 -> libpng16.so.16.40.0
/lib64/glibc-hwcaps/x86-64-v4: (hwcap: "x86-64-v4") (from <builtin>:0)
```
But note the directory names have changed. When the feature was added in 2017, the subdirs were "haswell" and "haswell/avx512_1" and compatibility with the old names has since been removed. On Rocky Linux 8 (glibc 2.28):
```
# ldconfig -v -N -X 2> /dev/null
/lib: (from <builtin>:0)
/lib64: (from <builtin>:0)
bunch of libraries
/lib64/glibc-hwcaps/x86-64-v4: (hwcap: "x86-64-v4") (from <builtin>:0)
/lib64/glibc-hwcaps/x86-64-v3: (hwcap: "x86-64-v3") (from <builtin>:0)
/lib64/glibc-hwcaps/x86-64-v2: (hwcap: "x86-64-v2") (from <builtin>:0)
/lib/sse2: (hwcap: 0x0000000000000001) (from <builtin>:0)
/lib64/sse2: (hwcap: 0x0000000000000001) (from <builtin>:0)
/lib64/tls: (hwcap: 0x8000000000000000) (from <builtin>:0)
/lib64/haswell: (hwcap: 0x0004000000000000) (from <builtin>:0)
/lib64/haswell/avx512_1: (hwcap: 0x0004000000000004) (from <builtin>:0)
```
Therefore, for maximum compatibility, CMake MAY deploy using both new and old names, using symlinks to link one to the other. Using as example my multi-subarch build of QtCore:
```
$ find -name libQt6Core.so.6 -ls
1997362 0 lrwxrwxrwx 1 tjmaciei users 21 Jun 23 08:56 ./libQt6Core.so.6 -> libQt6Core.so.6.7.0
1998005 0 lrwxrwxrwx 1 tjmaciei users 21 Jun 23 08:56 ./glibc-hwcaps/x86-64-v4/libQt6Core.so.6 -> libQt6Core.so.6.7.0
1997623 0 lrwxrwxrwx 1 tjmaciei users 21 Jun 23 08:56 ./glibc-hwcaps/x86-64-v3/libQt6Core.so.6 -> libQt6Core.so.6.7.0
1997365 0 lrwxrwxrwx 1 tjmaciei users 43 Jun 23 08:56 ./haswell/libQt6Core.so.6 -> ../glibc-hwcaps/x86-64-v3/libQt6Core.so.6
1997367 0 lrwxrwxrwx 1 tjmaciei users 46 Jun 23 08:56 ./haswell/avx512_1/libQt6Core.so.6 -> ../../glibc-hwcaps/x86-64-v4/libQt6Core.so.6
```https://gitlab.kitware.com/cmake/cmake/-/issues/24935CMake randomly stops building correctly on OS X 12.62023-05-24T12:16:42-04:00Ricardo MatiasCMake randomly stops building correctly on OS X 12.6I don't know whats happening, but I have this project that randomly stops working and there's this `-search_paths_first` error pops up. It doesn't always happen and I can't figure out what exactly triggers it.
cmake version 3.26.4
Mac O...I don't know whats happening, but I have this project that randomly stops working and there's this `-search_paths_first` error pops up. It doesn't always happen and I can't figure out what exactly triggers it.
cmake version 3.26.4
Mac OS X 12.6.6
compiler: arm-none-eabi-gcc 10.3.1
```
[main] Configuring project: pirack
[proc] Executing command: /usr/local/bin/cmake --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE:STRING=/Users/feral/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-g++ -S/Users/feral/Projects/DIY/pico/pirack -B/Users/feral/Projects/DIY/pico/pirack/build -G Ninja
[cmake] Using PICO_SDK_PATH from environment ('/Users/feral/Projects/DIY/pico/LIBRARIES/pico-sdk')
[cmake] Not searching for unused variables given on the command line.
[cmake] PICO_SDK_PATH is /Users/feral/Projects/DIY/pico/LIBRARIES/pico-sdk
[cmake] Defaulting PICO_PLATFORM to rp2040 since not specified.
[cmake] -- The CXX compiler identification is GNU 10.3.1
[cmake] -- The C compiler identification is GNU 10.3.1
[cmake] -- The ASM compiler identification is GNU
[cmake] -- Found assembler: /usr/local/bin/arm-none-eabi-gcc
[cmake] -- Checking whether CXX compiler has -isysroot
[cmake] -- Checking whether CXX compiler has -isysroot - yes
[cmake] -- Checking whether CXX compiler supports OSX deployment target flag
[cmake] -- Checking whether CXX compiler supports OSX deployment target flag - no
[cmake] -- Detecting CXX compiler ABI info
[cmake] -- Detecting CXX compiler ABI info - failed
[cmake] -- Check for working CXX compiler: /usr/local/bin/arm-none-eabi-g++
[cmake] -- Check for working CXX compiler: /usr/local/bin/arm-none-eabi-g++ - broken
[cmake] CMake Error at /usr/local/Cellar/cmake/3.26.4/share/cmake/Modules/CMakeTestCXXCompiler.cmake:60 (message):
[cmake] The C++ compiler
[cmake]
[cmake] "/usr/local/bin/arm-none-eabi-g++"
[cmake]
[cmake] is not able to compile a simple test program.
[cmake]
[cmake] It fails with the following output:
[cmake]
[cmake] Change Dir: /Users/feral/Projects/DIY/pico/pirack/build/CMakeFiles/CMakeScratch/TryCompile-K4bU0Z
[cmake]
[cmake] Run Build Command(s):/usr/local/bin/ninja -v cmTC_c8709 && [1/2] /usr/local/bin/arm-none-eabi-g++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -o CMakeFiles/cmTC_c8709.dir/testCXXCompiler.cxx.o -c /Users/feral/Projects/DIY/pico/pirack/build/CMakeFiles/CMakeScratch/TryCompile-K4bU0Z/testCXXCompiler.cxx
[cmake] [2/2] : && /usr/local/bin/arm-none-eabi-g++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/usr/local/opt/opencv@2/lib CMakeFiles/cmTC_c8709.dir/testCXXCompiler.cxx.o -o cmTC_c8709 && :
[cmake] FAILED: cmTC_c8709
[cmake] : && /usr/local/bin/arm-none-eabi-g++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/usr/local/opt/opencv@2/lib CMakeFiles/cmTC_c8709.dir/testCXXCompiler.cxx.o -o cmTC_c8709 && :
[cmake] /usr/local/Cellar/arm-none-eabi-gcc/10.3-2021.07/gcc/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: Error: unable to disambiguate: -search_paths_first (did you mean --search_paths_first ?)
[cmake] collect2: error: ld returned 1 exit status
[cmake] ninja: build stopped: subcommand failed.
[cmake]
[cmake]
[cmake]
[cmake]
[cmake]
[cmake] CMake will not be able to correctly generate this project.
[cmake] Call Stack (most recent call first):
[cmake] CMakeLists.txt:9 (project)
[cmake]
[cmake]
[cmake] -- Configuring incomplete, errors occurred!
[proc] The command: /usr/local/bin/cmake --no-warn-unused-cli -DCMAKE_TOOLCHAIN_FILE:STRING=/Users/feral/vcpkg/scripts/buildsystems/vcpkg.cmake -DCMAKE_EXPORT_COMPILE_COMMANDS:BOOL=TRUE -DCMAKE_BUILD_TYPE:STRING=Debug -DCMAKE_C_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-gcc -DCMAKE_CXX_COMPILER:FILEPATH=/usr/local/bin/arm-none-eabi-g++ -S/Users/feral/Projects/DIY/pico/pirack -B/Users/feral/Projects/DIY/pico/pirack/build -G Ninja exited with code: 1
```https://gitlab.kitware.com/cmake/cmake/-/issues/24348FindPNG can get confused when multiple versions of libpng are installed2023-02-02T14:15:41-05:00David GowFindPNG can get confused when multiple versions of libpng are installedMany linux systems have multiple versions of libpng installed, and CMake's FindPNG can sometimes get confused and provide mismatched headers and library versions. This is particularly likely if the "default" version of libpng (the one li...Many linux systems have multiple versions of libpng installed, and CMake's FindPNG can sometimes get confused and provide mismatched headers and library versions. This is particularly likely if the "default" version of libpng (the one libpng.so links to) is not the latest version.
For example, on my OpenSUSE Tumbleweed system, find_package(PNG) will give the path to libpng16 headers (``/usr/include/libpng16``), but the libpng12 library (``/usr/lib64/libpng.so``, which is a symlink to ``/usr/lib64/libpng12.so``).
This can result in somewhat inscrutable errors when available functions do not match, e.g.:
```
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/julius.dir/src/graphics/screenshot.c.o: in function `image_write_header':
screenshot.c:(.text+0x26e): undefined reference to `png_set_longjmp_fn'
/usr/lib64/gcc/x86_64-suse-linux/12/../../../../x86_64-suse-linux/bin/ld: CMakeFiles/julius.dir/src/graphics/screenshot.c.o: in function `image_write_rows':
screenshot.c:(.text+0x364): undefined reference to `png_set_longjmp_fn'
collect2: error: ld returned 1 exit status
```
Using pkg-config to look up individual versions of PNG works, as it will use the correct matching versions.
For example, see this PR for the Julius project, which shows pkg-config being used:
https://github.com/bvschaik/julius/pull/674/fileshttps://gitlab.kitware.com/cmake/cmake/-/issues/24314IntelLLVM: Add support for GNU-like front-ends on Windows2023-01-13T13:41:43-05:00Brad KingIntelLLVM: Add support for GNU-like front-ends on WindowsIntel oneAPI 2023 adds the GNU-like front-ends `icpx` and `icx-cc` on Windows. CMake needs to be taught how to use these.Intel oneAPI 2023 adds the GNU-like front-ends `icpx` and `icx-cc` on Windows. CMake needs to be taught how to use these.https://gitlab.kitware.com/cmake/cmake/-/issues/24174macOS: NAMELINK variants of shared library break Xcode import2022-11-18T17:56:55-05:00Patrick HeyermacOS: NAMELINK variants of shared library break Xcode importCMake generates 3 output files for a shared library on macOS:
* The main library `library.MAJOR.MINOR.PATCH.dylib`
* A major compatibility version symlink `library.MAJOR.dylib`
* An unversioned symlink `library.dylib`
Usually the varia...CMake generates 3 output files for a shared library on macOS:
* The main library `library.MAJOR.MINOR.PATCH.dylib`
* A major compatibility version symlink `library.MAJOR.dylib`
* An unversioned symlink `library.dylib`
Usually the variant with the entire semver in its filename is the "actual" file, whereas the other two variants are symlinks.
From my observation the canonical way to generate these is to have both symlinks point _directly_ to the actual dynamic library:
```
9,0M Okt 15 21:29 libavcodec.59.37.100.dylib
26 Okt 15 21:29 libavcodec.59.dylib -> libavcodec.59.37.100.dylib
26 Okt 15 21:29 libavcodec.dylib -> libavcodec.59.37.100.dylib
```
CMake however generates a "chain" of symlinks:
```
90K Nov 17 21:44 libjansson.4.14.0.dylib
23 Nov 17 21:44 libjansson.4.dylib -> libjansson.4.14.0.dylib
18 Nov 17 21:44 libjansson.dylib -> libjansson.4.dylib
```
In my tests this trips up Xcode when specifying libraries to be copied into an app bundle's "Frameworks" directory (via the `XCODE_EMBED_FRAMEWORKS` target property), which uses an internal copy tool to move the files into the bundle, but doesn't resolve entire symlink chains.
In the above example, the CMake finder looks for a library called "libjansson", finds the symlink and keeps that as the `LIBRARY_LOCATION` target property. `clang`'s linker doesn't seem to have any issue resolving this chain, but when composing the app bundle, Xcode will fail when it tries to codesign copied frameworks/libraries as the first symlink level was resolved, but instead `libjansson.4.dylib` was copied which is just a symlink.
From what I could tell, the correct way to generate these libraries is to have the compatibility versions link to the _actual_ library file and not generate a symlink chain, which would also fix the issue with Xcode.https://gitlab.kitware.com/cmake/cmake/-/issues/24108CrayLinuxEnvironment no longer sets CMAKE_SYSTEM_VERSION correctly2022-10-31T16:09:43-04:00Mark StockCrayLinuxEnvironment no longer sets CMAKE_SYSTEM_VERSION correctlySetting `CMAKE_SYSTEM_NAME=CrayLinuxEnvironment` when running cmake on HPE Cray systems (COS 2.3.88) results in the message "Unable to determine CLE version".
See the requisite file in CMake: https://github.com/Kitware/CMake/blob/v3.24....Setting `CMAKE_SYSTEM_NAME=CrayLinuxEnvironment` when running cmake on HPE Cray systems (COS 2.3.88) results in the message "Unable to determine CLE version".
See the requisite file in CMake: https://github.com/Kitware/CMake/blob/v3.24.2/Modules/Platform/CrayLinuxEnvironment.cmake
It seems that recent versions of "HPE Cray OS" do not set the environment variables mentioned in the above file, nor do they have the RELEASE key in `/etc/opt/cray/release/cle-release` (which is sym-linked to `/opt/cray/etc/release/cos` now). The `/opt/cray/etc/release/cos` file now contains:
```
PRODUCT="HPE Cray OS"
OS=SLES15SP3
ARCH=x86_64
VERSION=2.3
DATE=20220328210212
```https://gitlab.kitware.com/cmake/cmake/-/issues/24045IntelLLVM: Unable to set oneAPI-specific C++ compiler flags in combination wi...2022-10-11T13:03:25-04:00Dirk AdlerIntelLLVM: Unable to set oneAPI-specific C++ compiler flags in combination with Visual StudioHello,
I'm using Visual Studio 2022 with the Intel oneApi 2022 C++ Compiler and CMake 3.23.1. Everything works as expected expect setting some specific Intel C++ compiler flags.
E.g. For optimization Visual Studio supports Od, O1, O2 ...Hello,
I'm using Visual Studio 2022 with the Intel oneApi 2022 C++ Compiler and CMake 3.23.1. Everything works as expected expect setting some specific Intel C++ compiler flags.
E.g. For optimization Visual Studio supports Od, O1, O2 and Ox.
The Intel C++ Compiler supports Od, O1, O2, Ox and O3[Intel C++].
I can set all flags expect the O3 and some optimization diagnostic flags supported by the Intel compiler.
I tried it in multiple ways.
Changing the current flag like this:
```
MESSAGE(STATUS "CMAKE_CXX_FLAGS_RELEASE: ${CMAKE_CXX_FLAGS_RELEASE}")
string(REGEX REPLACE "/O[0-4]" "/O3" CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE}")
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE}" CACHE STRING "" FORCE)
MESSAGE(STATUS "CMAKE_CXX_FLAGS_RELEASE: ${CMAKE_CXX_FLAGS_RELEASE}")
```
The CXX_FLAG contains the Value O3, but when I open Visual Studio it is still set zo O2.
I also tried to overwrite the initial CXX flags
`set(CMAKE_USER_MAKE_RULES_OVERRIDE_CXX "${CMAKE_CURRENT_SOURCE_DIR}/cmake/cxx_flags_override.cmake")`
with
```
if (("${CMAKE_CXX_COMPILER_ID}" MATCHES "IntelLLVM"))
set(CMAKE_CXX_FLAGS_RELEASE_INIT "/MD /O3 /Ob2 /DNDEBUG /Qopt-report:3 /Qopt-report-phase:loop /Qopt-report-file:C:/Temp/ICX.dat")
message(STATUS "Overrides default compiler flags!")
else()
message(FATAL_ERROR "Overrides not set for compiler ${CMAKE_CXX_COMPILER_ID}")
endif()
```
but the behavior is still the same. The flag is still O2.
A minimum CMake file looks like that:
```
set(CMAKE_USER_MAKE_RULES_OVERRIDE_CXX "${CMAKE_CURRENT_SOURCE_DIR}/cmake/cxx_flags_override.cmake")
project(IntelTest)
set(EXECUTABLE_NAME intelTest)
cmake_minimum_required(VERSION 3.22)
set(CMAKE_CONFIGURATION_TYPES "Debug;Release")
add_executable(${EXECUTABLE_NAME}
main.cpp
)
```
The main is not doing anything right now:
```
#include <iostream>
#if defined( __INTEL_LLVM_COMPILER )
#endif
#if defined( _MSC_VER ) && ! defined( __INTEL_LLVM_COMPILER )
#endif
int main(int argc, char** argv)
{
std::cout << "Intel Test!!!" << std::endl;
return 0;
}
```
If I use Ninja to build the project, the flags for optimization are accepted and the diagnostic is written to file.
```
REM Set Intel C++ compiler variables
call "C:\Program Files (x86)\Intel\oneAPI\compiler\2022.2.0\env\vars.bat"
REM Create the project
cmake -G Ninja -B build-ninja -DCMAKE_MAKE_PROGRAM="ninja.exe" -DCMAKE_C_COMPILER="C:/Program Files (x86)/Intel/oneAPI/compiler/2022.2.0/windows/bin/icx.exe" -DCMAKE_CXX_COMPILER="C:/Program Files (x86)/Intel/oneAPI/compiler/2022.2.0/windows/bin/icx.exe" -DCMAKE_BUILD_TYPE=Release
cd build-ninja
REM Build the project
cmake --build . --config Release --verbose --clean-first
cd ..
```
A discussion about the topic in the CMake community can be found here:
https://discourse.cmake.org/t/intel-oneapi-c-compiler-with-visual-studio-2022/6634/3
Thanks and best regards,
Dirkhttps://gitlab.kitware.com/cmake/cmake/-/issues/23525FortranCInterface broken with GCC 12.0 if LTO is disabled2022-06-15T09:50:54-04:00Benjamin BuchFortranCInterface broken with GCC 12.0 if LTO is disabledI did build a docker image based on Ubuntu 22.04 for cross compilation to Windows.
```docker
FROM ubuntu:22.04
WORKDIR /mnt
ENV SYSROOT=/sysroot/usr
ARG PKG_CONFIG_VERSION=0.29.2
ARG CMAKE_VERSION=3.23.2
ARG BINUTILS_VERSION=2.38
ARG...I did build a docker image based on Ubuntu 22.04 for cross compilation to Windows.
```docker
FROM ubuntu:22.04
WORKDIR /mnt
ENV SYSROOT=/sysroot/usr
ARG PKG_CONFIG_VERSION=0.29.2
ARG CMAKE_VERSION=3.23.2
ARG BINUTILS_VERSION=2.38
ARG MINGW_VERSION=10.0.0
ARG GCC_VERSION=12.1.0
ARG NASM_VERSION=2.15.05
SHELL [ "/bin/bash", "-c" ]
RUN set -ex \
\
&& apt-get update \
&& DEBIAN_FRONTEND=noninteractive apt-get upgrade --no-install-recommends -y \
&& DEBIAN_FRONTEND=noninteractive apt-get install --no-install-recommends -y \
ca-certificates \
gcc \
g++ \
zlib1g-dev \
libssl-dev \
libgmp-dev \
libmpfr-dev \
libmpc-dev \
libisl-dev \
xz-utils \
python3 \
python3-lxml \
python3-mako \
ninja-build \
meson \
gnupg \
bzip2 \
patch \
curl \
smbclient \
gnuplot \
doxygen \
graphviz \
graphicsmagick \
imagemagick \
inkscape \
nano \
gperf \
bison \
file \
flex \
make \
yasm \
wget \
zip \
git \
texinfo \
wine \
\
&& wget -q https://pkg-config.freedesktop.org/releases/pkg-config-${PKG_CONFIG_VERSION}.tar.gz -O - | tar -xz \
&& wget -q https://github.com/Kitware/CMake/releases/download/v${CMAKE_VERSION}/cmake-${CMAKE_VERSION}.tar.gz -O - | tar -xz \
&& wget -q https://ftp.gnu.org/gnu/binutils/binutils-${BINUTILS_VERSION}.tar.xz -O - | tar -xJ \
&& wget -q https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v${MINGW_VERSION}.tar.bz2 -O - | tar -xj \
&& wget -q https://ftp.gnu.org/gnu/gcc/gcc-${GCC_VERSION}/gcc-${GCC_VERSION}.tar.xz -O - | tar -xJ \
&& wget -q https://www.nasm.us/pub/nasm/releasebuilds/${NASM_VERSION}/nasm-${NASM_VERSION}.tar.xz -O - | tar -xJ \
\
&& mkdir -p ${SYSROOT}/include ${SYSROOT}/lib/pkgconfig \
&& chmod 0777 -R /mnt ${SYSROOT} \
\
&& cd pkg-config-${PKG_CONFIG_VERSION} \
&& ./configure \
--prefix=/usr/local \
--with-pc-path=${SYSROOT}/lib/pkgconfig \
--with-internal-glib \
--disable-shared \
--disable-nls \
&& make -j $(nproc) \
&& make install \
&& cd .. \
\
&& cd cmake-${CMAKE_VERSION} \
&& ./configure \
--prefix=/usr/local \
--parallel=$(nproc) \
&& make -j $(nproc) \
&& make install \
&& cd .. \
\
&& cd binutils-${BINUTILS_VERSION} \
&& ./configure \
--prefix=/usr/local \
--target=x86_64-w64-mingw32 \
--disable-shared \
--enable-static \
--disable-lto \
--disable-plugins \
--disable-multilib \
--disable-nls \
--disable-werror \
--with-system-zlib \
&& make -j $(nproc) \
&& make install \
&& cd .. \
\
&& mkdir mingw-w64 \
&& cd mingw-w64 \
&& ../mingw-w64-v${MINGW_VERSION}/mingw-w64-headers/configure \
--prefix=/usr/local/x86_64-w64-mingw32 \
--host=x86_64-w64-mingw32 \
--enable-sdk=all \
--enable-secure-api \
&& make install \
&& cd .. \
&& ln -s /usr/local/x86_64-w64-mingw32/include/windows.h /usr/local/x86_64-w64-mingw32/include/Windows.h \
&& ln -s /usr/local/x86_64-w64-mingw32/include/setupapi.h /usr/local/x86_64-w64-mingw32/include/SetupAPI.h \
\
&& mkdir gcc \
&& cd gcc \
&& ../gcc-${GCC_VERSION}/configure \
--prefix=/usr/local \
--target=x86_64-w64-mingw32 \
--enable-languages=c,c++,fortran \
--disable-shared \
--enable-static \
--enable-threads=posix \
--with-system-zlib \
--enable-libgomp \
--enable-libatomic \
--enable-graphite \
--disable-libstdcxx-pch \
--disable-libstdcxx-debug \
--disable-multilib \
--disable-lto \
--disable-nls \
--disable-werror \
&& make -j $(nproc) all-gcc \
&& make install-gcc \
&& cd .. \
\
&& cd mingw-w64 \
&& ../mingw-w64-v${MINGW_VERSION}/mingw-w64-crt/configure \
--prefix=/usr/local/x86_64-w64-mingw32 \
--host=x86_64-w64-mingw32 \
--enable-wildcard \
--disable-lib32 \
--enable-lib64 \
&& make -j $(nproc) \
&& make install \
&& cd .. \
\
&& cd mingw-w64 \
&& ../mingw-w64-v${MINGW_VERSION}/mingw-w64-libraries/winpthreads/configure \
--prefix=/usr/local/x86_64-w64-mingw32 \
--host=x86_64-w64-mingw32 \
--enable-static \
--disable-shared \
&& make -j $(nproc) \
&& make install \
&& cd .. \
\
&& cd gcc \
&& make -j $(nproc) \
&& make install \
&& cd .. \
\
&& cd nasm-${NASM_VERSION} \
&& ./configure --prefix=/usr/local \
&& make -j $(nproc) \
&& make install \
&& cd .. \
\
&& rm -r pkg-config-${PKG_CONFIG_VERSION} \
&& rm -r cmake-${CMAKE_VERSION} \
&& rm -r binutils-${BINUTILS_VERSION} \
&& rm -r mingw-w64 mingw-w64-v${MINGW_VERSION} \
&& rm -r gcc gcc-${GCC_VERSION} \
&& rm -r nasm-${NASM_VERSION} \
\
&& apt-get remove --purge -y file zlib1g-dev libssl-dev libgmp-dev libmpfr-dev libmpc-dev libisl-dev python3-lxml python3-mako \
\
&& apt-get remove --purge -y gnupg \
&& apt-get autoremove --purge -y \
&& apt-get clean
ENV CMAKE_VARS=" -Wno-dev -DCMAKE_BUILD_TYPE=Release -DCMAKE_SYSTEM_PROCESSOR=x86_64 -DCMAKE_SYSTEM_NAME=Windows -DCMAKE_SYSTEM_VERSION=10.0 -DCMAKE_INSTALL_PREFIX=$SYSROOT -DCMAKE_FIND_ROOT_PATH=$SYSROOT -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY=ONLY -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE=ONLY -DCMAKE_C_COMPILER=x86_64-w64-mingw32-gcc -DCMAKE_CXX_COMPILER=x86_64-w64-mingw32-g++ -DCMAKE_RC_COMPILER=x86_64-w64-mingw32-windres -DCMAKE_Fortran_COMPILER=x86_64-w64-mingw32-gfortran -DCMAKE_FIND_ROOT_PATH=/sysroot/usr;/usr/local/x86_64-w64-mingw32" \
CONFIGURE_VARS="--host=x86_64-w64-mingw32 --with-sysroot=$SYSROOT --prefix=$SYSROOT"
```
Based on this I try to build lapack via:
```bash
LAPACK_VERSION=3.10.1
# download
cd /mnt
curl -L https://github.com/Reference-LAPACK/lapack/archive/v${LAPACK_VERSION}.tar.gz | tar xz
# build, install
mkdir -p /mnt/build && cd $_
cmake $CMAKE_VARS /mnt/lapack-${LAPACK_VERSION}
```
Cmake fails with:
```
-- The Fortran compiler identification is GNU 12.1.0
-- The C compiler identification is GNU 12.1.0
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /usr/local/bin/x86_64-w64-mingw32-gfortran - skipped
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/local/bin/x86_64-w64-mingw32-gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Checking if build type is 'Coverage'
-- Checking if build type is 'Coverage': 0
-- Performing Test _frecursiveFlag
-- Performing Test _frecursiveFlag - Success
-- Build tests: OFF
-- Reducing RELEASE optimization level to O2
-- Looking for Fortran NONE - found
-- Looking for Fortran INT_CPU_TIME - found
-- Looking for Fortran EXT_ETIME - not found
-- Looking for Fortran EXT_ETIME_ - not found
-- Looking for Fortran INT_ETIME - found
-- --> Will use second_INT_ETIME.f and dsecnd_INT_ETIME.f as timing function.
-- Build deprecated routines: OFF
-- Build single precision real: ON
-- Build double precision real: ON
-- Build single precision complex: ON
-- Build double precision complex: ON
-- Using supplied NETLIB BLAS implementation
-- Using supplied NETLIB LAPACK implementation
-- Detecting Fortran/C Interface
Failed to compile
-- Verifying Fortran/C Compiler Compatibility
Failed to compile
-- Verifying Fortran/C Compiler Compatibility - Failed
CMake Error at /usr/local/share/cmake-3.23/Modules/FortranCInterface.cmake:400 (message):
The Fortran compiler:
/usr/local/bin/x86_64-w64-mingw32-gfortran
and the C compiler:
/usr/local/bin/x86_64-w64-mingw32-gcc
failed to compile a simple test project using both languages. The output
was:
Change Dir: /mnt/build/CMakeFiles/FortranCInterface/VerifyC
Run Build Command(s):/usr/bin/gmake -f Makefile VerifyFortranC && /usr/local/bin/cmake -S/usr/local/share/cmake-3.23/Modules/FortranCInterface/Verify -B/mnt/build/CMakeFiles/FortranCInterface/VerifyC --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/gmake -f CMakeFiles/Makefile2 VerifyFortranC
gmake[1]: Entering directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
/usr/local/bin/cmake -S/usr/local/share/cmake-3.23/Modules/FortranCInterface/Verify -B/mnt/build/CMakeFiles/FortranCInterface/VerifyC --check-build-system CMakeFiles/Makefile.cmake 0
/usr/local/bin/cmake -E cmake_progress_start /mnt/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles 5
/usr/bin/gmake -f CMakeFiles/Makefile2 CMakeFiles/VerifyFortranC.dir/all
gmake[2]: Entering directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
/usr/bin/gmake -f CMakeFiles/VerifyFortran.dir/build.make CMakeFiles/VerifyFortran.dir/depend
gmake[3]: Entering directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
cd /mnt/build/CMakeFiles/FortranCInterface/VerifyC && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /usr/local/share/cmake-3.23/Modules/FortranCInterface/Verify /usr/local/share/cmake-3.23/Modules/FortranCInterface/Verify /mnt/build/CMakeFiles/FortranCInterface/VerifyC /mnt/build/CMakeFiles/FortranCInterface/VerifyC /mnt/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/VerifyFortran.dir/DependInfo.cmake
Scanning dependencies of target VerifyFortran
gmake[3]: Leaving directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
/usr/bin/gmake -f CMakeFiles/VerifyFortran.dir/build.make CMakeFiles/VerifyFortran.dir/build
gmake[3]: Entering directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
[ 20%] Building Fortran object CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o
/usr/local/bin/x86_64-w64-mingw32-gfortran @CMakeFiles/VerifyFortran.dir/includes_Fortran.rsp -frecursive -O2 -DNDEBUG -O2 -c /usr/local/share/cmake-3.23/Modules/FortranCInterface/Verify/VerifyFortran.f -o CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o
[ 40%] Linking Fortran static library libVerifyFortran.a
/usr/local/bin/cmake -P CMakeFiles/VerifyFortran.dir/cmake_clean_target.cmake
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/VerifyFortran.dir/link.txt --verbose=1
/usr/local/bin/x86_64-w64-mingw32-ar qc libVerifyFortran.a CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o
/usr/local/bin/x86_64-w64-mingw32-ranlib libVerifyFortran.a
gmake[3]: Leaving directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
[ 40%] Built target VerifyFortran
/usr/bin/gmake -f CMakeFiles/VerifyFortranC.dir/build.make CMakeFiles/VerifyFortranC.dir/depend
gmake[3]: Entering directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
cd /mnt/build/CMakeFiles/FortranCInterface/VerifyC && /usr/local/bin/cmake -E cmake_depends "Unix Makefiles" /usr/local/share/cmake-3.23/Modules/FortranCInterface/Verify /usr/local/share/cmake-3.23/Modules/FortranCInterface/Verify /mnt/build/CMakeFiles/FortranCInterface/VerifyC /mnt/build/CMakeFiles/FortranCInterface/VerifyC /mnt/build/CMakeFiles/FortranCInterface/VerifyC/CMakeFiles/VerifyFortranC.dir/DependInfo.cmake
Scanning dependencies of target VerifyFortranC
gmake[3]: Leaving directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
/usr/bin/gmake -f CMakeFiles/VerifyFortranC.dir/build.make CMakeFiles/VerifyFortranC.dir/build
gmake[3]: Entering directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
[ 60%] Building C object CMakeFiles/VerifyFortranC.dir/main.c.obj
/usr/local/bin/x86_64-w64-mingw32-gcc @CMakeFiles/VerifyFortranC.dir/includes_C.rsp -O3 -DNDEBUG -o CMakeFiles/VerifyFortranC.dir/main.c.obj -c /usr/local/share/cmake-3.23/Modules/FortranCInterface/Verify/main.c
[ 80%] Building C object CMakeFiles/VerifyFortranC.dir/VerifyC.c.obj
/usr/local/bin/x86_64-w64-mingw32-gcc @CMakeFiles/VerifyFortranC.dir/includes_C.rsp -O3 -DNDEBUG -o CMakeFiles/VerifyFortranC.dir/VerifyC.c.obj -c /usr/local/share/cmake-3.23/Modules/FortranCInterface/Verify/VerifyC.c
[100%] Linking C executable VerifyFortranC.exe
/usr/local/bin/cmake -E cmake_link_script CMakeFiles/VerifyFortranC.dir/link.txt --verbose=1
/usr/local/bin/cmake -E rm -f CMakeFiles/VerifyFortranC.dir/objects.a
/usr/local/bin/x86_64-w64-mingw32-ar qc CMakeFiles/VerifyFortranC.dir/objects.a @CMakeFiles/VerifyFortranC.dir/objects1.rsp
/usr/local/bin/x86_64-w64-mingw32-gcc -O3 -DNDEBUG -Wl,--whole-archive CMakeFiles/VerifyFortranC.dir/objects.a -Wl,--no-whole-archive -o VerifyFortranC.exe -Wl,--out-implib,libVerifyFortranC.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles/VerifyFortranC.dir/linklibs.rsp
/usr/local/lib/gcc/x86_64-w64-mingw32/12.1.0/../../../../x86_64-w64-mingw32/bin/ld: CMakeFiles/VerifyFortranC.dir/objects.a(main.c.obj):main.c:(.text.startup+0xf): undefined reference to `VerifyFortran'
collect2: error: ld returned 1 exit status
gmake[3]: *** [CMakeFiles/VerifyFortranC.dir/build.make:119: VerifyFortranC.exe] Error 1
gmake[3]: Leaving directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
gmake[2]: *** [CMakeFiles/Makefile2:114: CMakeFiles/VerifyFortranC.dir/all] Error 2
gmake[2]: Leaving directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
gmake[1]: *** [CMakeFiles/Makefile2:121: CMakeFiles/VerifyFortranC.dir/rule] Error 2
gmake[1]: Leaving directory '/mnt/build/CMakeFiles/FortranCInterface/VerifyC'
gmake: *** [Makefile:140: VerifyFortranC] Error 2
Call Stack (most recent call first):
LAPACKE/CMakeLists.txt:4 (FortranCInterface_VERIFY)
-- Configuring incomplete, errors occurred!
See also "/mnt/build/CMakeFiles/CMakeOutput.log".
See also "/mnt/build/CMakeFiles/CMakeError.log".
```
If your replace `GCC_VERSION=12.1.0` with `GCC_VERSION=11.2.0` in the `Dockerfile`, everything works fine. If your enable LTO during GCC configuration also everything works as expected.
[cmake-dir.tar.gz](/uploads/6b31cd9af8871572287918668a9326cb/cmake-dir.tar.gz)https://gitlab.kitware.com/cmake/cmake/-/issues/21845Xcode: POST_BUILD runs before signing, breaks builds on ARM Mac2024-03-02T16:35:04-05:00Brad KingXcode: POST_BUILD runs before signing, breaks builds on ARM MacWith the Xcode generator on macOS arm64, the pattern
```cmake
add_executable(myexe myexe.c)
add_custom_command(TARGET myexe POST_BUILD COMMAND myexe)
```
fails to build. The `POST_BUILD` command generates a "Run Script" build phase wi...With the Xcode generator on macOS arm64, the pattern
```cmake
add_executable(myexe myexe.c)
add_custom_command(TARGET myexe POST_BUILD COMMAND myexe)
```
fails to build. The `POST_BUILD` command generates a "Run Script" build phase with a script that runs `myexe`, but Xcode's build system tries to run that phase before singing the executable.
The build fails with output:
```
Killed: 9 "/path/to/myexe"
Command PhaseScriptExecution failed with a nonzero exit code
```https://gitlab.kitware.com/cmake/cmake/-/issues/21609cmake-gui: Port away from deprecated QDirModel2020-12-21T10:56:40-05:00Brad Kingcmake-gui: Port away from deprecated QDirModel`QDirModel` has been deprecated since Qt 5.15. !4894 switched from `QDirModel` to `QFileSystemModel`, but !5619 reverted back to `QDirModel` due to #21589. See https://gitlab.kitware.com/cmake/cmake/-/issues/21589#note_873570 in partic...`QDirModel` has been deprecated since Qt 5.15. !4894 switched from `QDirModel` to `QFileSystemModel`, but !5619 reverted back to `QDirModel` due to #21589. See https://gitlab.kitware.com/cmake/cmake/-/issues/21589#note_873570 in particular.
!5619 left a FIXME comment to resolve this while not breaking completion of partial path edits.https://gitlab.kitware.com/cmake/cmake/-/issues/20366FindOpenMP fails if the build directory contains a colon character (:)2020-02-24T11:22:39-05:00Davide MancusiFindOpenMP fails if the build directory contains a colon character (:)Minimal reproducer:
```
$ cat >CMakeLists.txt <<EOF
cmake_minimum_required(VERSION 3.16)
project(bug C)
find_package(OpenMP REQUIRED)
EOF
$ mkdir build:it
$ cd build:it
$ cmake ..
-- The C compiler identification is GNU 5.4.0
-- Check f...Minimal reproducer:
```
$ cat >CMakeLists.txt <<EOF
cmake_minimum_required(VERSION 3.16)
project(bug C)
find_package(OpenMP REQUIRED)
EOF
$ mkdir build:it
$ cd build:it
$ cmake ..
-- The C compiler identification is GNU 5.4.0
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
CMake Error at /usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:146 (message):
Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES)
Call Stack (most recent call first):
/usr/share/cmake-3.16/Modules/FindPackageHandleStandardArgs.cmake:393 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.16/Modules/FindOpenMP.cmake:511 (find_package_handle_standard_args)
CMakeLists.txt:3 (find_package)
-- Configuring incomplete, errors occurred!
See also "/home/arekfu/src/foo/build:it/CMakeFiles/CMakeOutput.log".
See also "/home/arekfu/src/foo/build:it/CMakeFiles/CMakeError.log".
```
Seen on CMake v3.16. CMake works fine if the build directory does not contain any colon characters.