CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-01-25T11:02:33-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25589CMake 3.28 Segfault in x86_64 container under macos arm64 and qemu-user-static2024-01-25T11:02:33-05:00Andrew MarshallCMake 3.28 Segfault in x86_64 container under macos arm64 and qemu-user-staticSummary
-------
SystemInformation test (and others) segfault on x86 container running under qemu-user-static on Apple Silicon
This is a bit of a niche scenario but it appears to be traceable to a single commit.
Expected Result
-------...Summary
-------
SystemInformation test (and others) segfault on x86 container running under qemu-user-static on Apple Silicon
This is a bit of a niche scenario but it appears to be traceable to a single commit.
Expected Result
---------------
All tests should pass
Actual Result
-------------
SystemInformationNew test and others result in Segfault
Steps to Reproduce
------------------
* CMake version: [5420639a](https://gitlab.kitware.com/cmake/cmake/-/commit/bc702aa97eb892208c2ad010129d52cae62fb73a) onwards
* Host: Macos Ventura 13.6.2 (Mac Book Pro M2)
* VM: Fedora Core (Podman VM)
* Container: Ubuntu 22.04
```
brew install podman
podman machine init
podman machine start
podman machine ssh 'sudo rpm-ostree install qemu-user-static'
podman machine stop
podman machine start
podman run --arch x86_64 -it ubuntu:22.04 /bin/bash
```
Then build and run cmake in the container
```
ctest --test-dir <build_dir> -R SystemInformationNew
```
Workaround
----------
Versions prior to 5420639a run successfully.https://gitlab.kitware.com/cmake/cmake/-/issues/25562cmake 3.28.x hanging on configure with arm64/rosetta2024-01-25T11:00:03-05:00Matias Lopezcmake 3.28.x hanging on configure with arm64/rosettaWe have been getting reports of devs on macOS builds hanging through docker. We have reproduce with both versions 3.28.x but not 3.27.6. We have reproduced with rhel 7, 8, and ubuntu. The only commonality is 3.28.x, macOS, docker with bu...We have been getting reports of devs on macOS builds hanging through docker. We have reproduce with both versions 3.28.x but not 3.27.6. We have reproduced with rhel 7, 8, and ubuntu. The only commonality is 3.28.x, macOS, docker with buildkit, and rosetta (because the images were for amd64).
<details>
<summary>files</summary>
```cml
cmake_minimum_required(VERSION 3.20)
project(Test)
```
```Dockerfile
FROM <IMAGE>
RUN yum install -y make.x86_64
COPY cmake-3.28.1-linux-x86_64.tar.gz /
RUN tar -xf /cmake-3.28.1-linux-x86_64.tar.gz
RUN mkdir /src/
COPY CMakeLists.txt /src/
COPY test.sh /src/
RUN chmod +x /src/test.sh
ENV PATH="${PATH}:/cmake-3.28.1-linux-x86_64/bin"
WORKDIR /src/
ENTRYPOINT [ "/src/test.sh" ]
```
```sh
#!/bin/sh
for i in `seq 1 10` ; do
mkdir build$i
cd build$i
cmake .. &
cd ..
done
wait
```
</details>
We suspect that it relates to https://gitlab.kitware.com/cmake/cmake/-/merge_requests/8665 from a trace we got while hung:
```
(gdb) where
#0 0x00007ffffecbd0c3 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1 0x0000000000e1b13d in uv.io_poll ()
#2 0x0000000000e0c066 in uv_run ()
#3 0x00000000006ab72e in cmExecuteProcessCommand(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, cmExecutionStatus&) ()
#4 0x00000000005dcc4f in std::_Function_handler<bool (std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&), cmState::AddBuiltinCommand(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool (*)(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, cmExecutionStatus&))::lambda(std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&)#1 <GO>>::_M_invoke(std::_Any_data const&, std::vector<cmListFileArgument, std::allocator<cmListFileArgument> > const&, cmExecutionStatus&) ()
#5 0x00000000005893a7 in cmMakefile::ExecuteCommand(cmListFileFunction const&, cmExecutionStatus&, std::optional<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >) ()
```https://gitlab.kitware.com/cmake/cmake/-/issues/25545CPack RPM can't deal with man pages properly, as it is not able to find them ...2024-01-16T11:24:41-05:00Raffaello BertiniCPack RPM can't deal with man pages properly, as it is not able to find them because rpmbuild compressed themwhen running cpack for RPM including some man pages files in a directory,
rpmbuild will compress them and remove the original files,
this will mismatch with the generated spec file that can't find the files.
besides the generated spe...when running cpack for RPM including some man pages files in a directory,
rpmbuild will compress them and remove the original files,
this will mismatch with the generated spec file that can't find the files.
besides the generated spec looks almost correct:
```rpmspec
%dir "/usr/share/man"
%dir "/usr/share/man/man1"
"/usr/share/man/man1/myapp.1*"
```
the content in that folder instead of having files in the `myapp.1` folder, there is the compressed file, `myapp.1.gz` in my case.
the output resulting is:
```
error: File not found: [...]/usr/share/man/man1/myapp.1\*
```
The fix is to replace the `"/usr/share/man/man1/myapp.1*"` with: `%{_mandir}/man1/myapp.1*`
when CPackRPM generates the spec filehttps://gitlab.kitware.com/cmake/cmake/-/issues/25387Please provide fully statically linked binaries of CMake2023-11-03T08:03:01-04:00John DoePlease provide fully statically linked binaries of CMakeAs per [this Discourse thread](https://discourse.cmake.org/t/please-provide-fully-statically-linked-binaries-of-cmake/9299) I'm opening an issue here.
The [CMake binaries for linux](https://github.com/Kitware/CMake/releases/download/v3....As per [this Discourse thread](https://discourse.cmake.org/t/please-provide-fully-statically-linked-binaries-of-cmake/9299) I'm opening an issue here.
The [CMake binaries for linux](https://github.com/Kitware/CMake/releases/download/v3.27.7/cmake-3.27.7-linux-x86_64.tar.gz) provided on the website have no dependencies except on GLIBC, which is linked dynamically...
Is it possible to instead provide linux binaries that are **fully statically linked** to [MUSL](https://musl.libc.org)? Such binaries will work out of the box on both GLIBC and MUSL distros, and also work on distros with a GLIBC that is too old/new.
The `cmake-gui` binary is the only exception, because it has other dependencies (Qt), however Qt can be built on MUSL and linked statically. Void Linux (musl version) offers working copies of Qt5 and Qt6, with patches:
[void-packages/tree/master/srcpkgs/qt5](https://github.com/void-linux/void-packages/tree/master/srcpkgs/qt5)
[void-packages/tree/master/srcpkgs/qt6-base](https://github.com/void-linux/void-packages/tree/master/srcpkgs/qt6-base)
Full list of qt5-\* and qt6-\* packages provided by Void are searchable on [this page](https://voidlinux.org/packages/?arch=x86_64-musl&q=qt5).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/25125if(EXISTS): checks for read permissions for files, not for existence2023-10-22T14:35:52-04:00Ruslan Baratovx@ruslo.devif(EXISTS): checks for read permissions for files, not for existenceTested OS:
```
> lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 22.04.2 LTS
Release: 22.04
Codename: jammy
```
CMake script:
```
> cat script.cmake
if(EXISTS "${CMAKE_CURRENT_LIST_DIR}/a.txt")
message...Tested OS:
```
> lsb_release -a
Distributor ID: Ubuntu
Description: Ubuntu 22.04.2 LTS
Release: 22.04
Codename: jammy
```
CMake script:
```
> cat script.cmake
if(EXISTS "${CMAKE_CURRENT_LIST_DIR}/a.txt")
message("OK")
else()
message("FAIL")
endif()
```
File to test:
```
> touch a.txt
> chmod +r a.txt
```
```
> cmake -P script.cmake
OK
```
Removing read permission, but not file:
```
> chmod -r a.txt
```
```
> ls a.txt
a.txt
```
```
> cmake -P script.cmake
FAIL
```
CMake version:
```
> cmake --version
cmake version 3.27.0
```
I guess it's here:
- https://gitlab.kitware.com/cmake/cmake/-/blob/v3.27.0/Source/kwsys/SystemTools.cxx#L1495
Not sure why `R_OK` is used there since `F_OK` is already mentioned.Marc ChevrierMarc Chevrierhttps://gitlab.kitware.com/cmake/cmake/-/issues/25017CPackRPM incorrectly sets DESTDIR for the pre-installation step (2023.06.21.)2023-07-17T07:59:59-04:00Attila KrasznahorkayCPackRPM incorrectly sets DESTDIR for the pre-installation step (2023.06.21.)This issue started out its life under: https://discourse.cmake.org/t/cpackrpm-installing-unnecessary-files But by now I'm pretty sure that there's an issue in the CMake code, so it seems better to put this into a ticket.
The back-story ...This issue started out its life under: https://discourse.cmake.org/t/cpackrpm-installing-unnecessary-files But by now I'm pretty sure that there's an issue in the CMake code, so it seems better to put this into a ticket.
The back-story of how I came across this issue is a bit complicated. But the simplest reproducer that I could come up with for the issue is the following:
```cmake
# Set up the project.
cmake_minimum_required(VERSION 3.10)
project(CPackWithExternalProject VERSION 1.0.0 LANGUAGES C)
# CMake include(s).
include(CPack)
include(ExternalProject)
# Build GoogleTest as an external package.
ExternalProject_Add(Eigen
INSTALL_DIR "${CMAKE_BINARY_DIR}/eigen"
URL "https://gitlab.com/libeigen/eigen/-/archive/3.3.7/eigen-3.3.7.tar.gz"
URL_MD5 "9e30f67e8531477de4117506fe44669b"
CMAKE_CACHE_ARGS
-DCMAKE_INSTALL_PREFIX:PATH=<INSTALL_DIR>
-DBUILD_TESTING:BOOL=FALSE
-DEIGEN_BUILD_DOC:BOOL=FALSE
-DEIGEN_TEST_NOQT:BOOL=TRUE)
```
When I build it with the "normal" configure->build->package chain of commands, I correctly get an empty RPM file.
```
Singularity> cmake ../source/
-- The C compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /cvmfs/sft.cern.ch/lcg/releases/gcc/11.2.0-8a51a/x86_64-centos7/bin/gcc - skipped
...
Singularity> make
[ 12%] Creating directories for 'Eigen'
[ 25%] Performing download step (download, verify and extract) for 'Eigen'
-- Downloading...
dst='/srv/build/Eigen-prefix/src/eigen-3.3.7.tar.gz'
timeout='none'
...
[100%] Completed 'Eigen'
[100%] Built target Eigen
Singularity> cpack -G RPM
CPack: Create package using RPM
CPack: Install projects
CPack: - Run preinstall target for: CPackWithExternalProject
CPack: - Install project: CPackWithExternalProject []
CPack: Create package
CPackRPM: Will use GENERATED spec file: /srv/build/_CPack_Packages/Linux/RPM/SPECS/cpackwithexternalproject.spec
CPack: - package: /srv/build/CPackWithExternalProject-1.0.0-Linux.rpm generated.
Singularity> ls -l CPackWithExternalProject-1.0.0-Linux.rpm
-rw-rw-r-- 1 krasznaa krasznaa 1812 Jun 20 20:19 CPackWithExternalProject-1.0.0-Linux.rpm
Singularity>
```
But if I try to do a not-completelt-standard configure->package series of commands, I get the following:
```
Singularity> cmake ../source/
-- The C compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /cvmfs/sft.cern.ch/lcg/releases/gcc/11.2.0-8a51a/x86_64-centos7/bin/gcc - skipped
...
-- Configuring done
-- Generating done
-- Build files have been written to: /srv/build
Singularity> cpack -G RPM
CPack: Create package using RPM
CPack: Install projects
CPack: - Run preinstall target for: CPackWithExternalProject
CPack: - Install project: CPackWithExternalProject []
CPack: Create package
CMake Warning (dev) at /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:188 (message):
CPackRPM:Warning: Path /srv/build/eigen/include/eigen3/Eigen/Cholesky is
not on one of the relocatable paths! Package will be partially relocatable.
Call Stack (most recent call first):
/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:1056 (cpack_rpm_prepare_relocation_paths)
/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:1968 (cpack_rpm_generate_package)
This warning is for project developers. Use -Wno-dev to suppress it.
...
CMake Warning (dev) at /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:188 (message):
CPackRPM:Warning: Path /srv/build/eigen/share/pkgconfig/eigen3.pc is not on
one of the relocatable paths! Package will be partially relocatable.
Call Stack (most recent call first):
/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:1056 (cpack_rpm_prepare_relocation_paths)
/cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64/Cmake/3.24.3/Linux-x86_64/share/cmake-3.24/Modules/Internal/CPack/CPackRPM.cmake:1968 (cpack_rpm_generate_package)
This warning is for project developers. Use -Wno-dev to suppress it.
CPackRPM: Will use GENERATED spec file: /srv/build/_CPack_Packages/Linux/RPM/SPECS/cpackwithexternalproject.spec
CPack: - package: /srv/build/CPackWithExternalProject-1.0.0-Linux.rpm generated.
Singularity> ls -l CPackWithExternalProject-1.0.0-Linux.rpm
-rw-rw-r-- 1 krasznaa krasznaa 1014476 Jun 20 20:22 CPackWithExternalProject-1.0.0-Linux.rpm
Singularity>
```
In this case a whole lot of unwanted files end up in the RPM file. Files that were meant to end up in `${CMAKE_BINARY_DIR}/eigen`, but because `$DESTDIR` is set by CPackRPM for the preinstall step, they rather end up in the directory that the RPM is built out of.
Note that I don't see anything like this when generating TGZ packages. Even when using
```cmake
if( "${CPACK_GENERATOR}" STREQUAL "TGZ" )
# CPACK_SET_DESTDIR is necessary for the TGZ generator when using the custom
# cpack_install.sh.in script, but must not be set for the RPM generator.
set( CPACK_SET_DESTDIR TRUE )
endif()
```
inside of [CPACK_PROJECT_CONFIG_FILE](https://cmake.org/cmake/help/latest/module/CPack.html#variable:CPACK_PROJECT_CONFIG_FILE). So I have a very strong suspicion that the source of all of these issues is in:
https://gitlab.kitware.com/cmake/cmake/-/blob/v3.26.4/Source/CPack/cmCPackRPMGenerator.cxx#L26-28
:thinking:https://gitlab.kitware.com/cmake/cmake/-/issues/24842Winelib (winegcc/wineg++) support2023-04-23T23:43:12-04:00Mingye WangWinelib (winegcc/wineg++) supportI saw [RFC: Investigate the winegcc/wineg++ support in CMake (via CMakeParseImplicit[Include/Link]Info or Compiler/Wine-GNU etc.)?](https://discourse.cmake.org/t/rfc-investigate-the-winegcc-wineg-support-in-cmake-via-cmakeparseimplicit-i...I saw [RFC: Investigate the winegcc/wineg++ support in CMake (via CMakeParseImplicit[Include/Link]Info or Compiler/Wine-GNU etc.)?](https://discourse.cmake.org/t/rfc-investigate-the-winegcc-wineg-support-in-cmake-via-cmakeparseimplicit-include-link-info-or-compiler-wine-gnu-etc/6589) by Alex but noticed that it has no issue actually filed after @ben.boeckel's suggestion, so here it is.
As Alex mentioned, winegcc is about linking to Windows libs in native (non-Windows) executables, and the library search routine needs to adapt somewhat. Well, winegcc potentially links to native `.so` (and `.dylib`) too per https://github.com/wine-mirror/wine/blob/7f90c9d7eb08891394f5d48448fd1a6cb5a67df9/tools/winegcc/winegcc.c#L916. All the types it looks for is in [`guess_lib_type()`](https://github.com/wine-mirror/wine/blob/7f90c9d7eb08891394f5d48448fd1a6cb5a67df9/tools/winegcc/utils.c#L120).
https://bugs.winehq.org/show_bug.cgi?id=51793 is a related issue tracking this thing on the Wine side.https://gitlab.kitware.com/cmake/cmake/-/issues/24621install(RUNTIME_DEPENDENCIES): Searches in DIRECTORIES although the dependenc...2023-03-23T10:55:49-04:00NelDavinstall(RUNTIME_DEPENDENCIES): Searches in DIRECTORIES although the dependency is found in rpath<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, pl...<!--
This issue tracker is for CMake upstream development:
* If you are having trouble building a specific third-party project
that uses CMake, ask for help in that project's forums first.
* If you have a coding or usage question, please ask for help
on the CMake discourse forums: https://discourse.cmake.org/
-->
When installing `RUNTIME_DEPENDENCIES`, the dependencies are search inside the usual paths first.
If they are not found there, they are searched inide ehe paths stated in `DIRECTORIES`.
This behavior is mentioned in the documentation and I think it is reasonable.
When using `RUNTIME_DEPENDENCIES` on Linux, the dependencies are search inside all `rpath` directories.
For some reasons, cmake also searches for them inside the `DIRECOTRIES` even if they are found inside on of the `rpath` directories.
When analyzing the output of cmake, it looks like cmake first searches inside the `DIRECOTRIES` paths and after that, the `rpath` directories are searched:
```
CMake Warning at src/batch/cmake_install.cmake:76 (file):
Dependency libQt5Core.so.5 found in search directory:
<external-dir-stated-in-DIRECOTRIES>
See file(GET_RUNTIME_DEPENDENCIES) documentation for more information.
Call Stack (most recent call first):
cmake_install.cmake:52 (include)
CMake Error at src/batch/cmake_install.cmake:76 (file):
file Multiple conflicting paths found for libQt5Core.so.5:
<external-dir-stated-in-DIRECOTRIES>/libQt5Core.so.5
/Qt5.15.2/5.15.2/gcc_64/lib/libQt5Core.so.5
Call Stack (most recent call first):
cmake_install.cmake:52 (include)
```
Note that `/Qt5.15.2/5.15.2/gcc_64/lib` is part of the `BUILD_RPATH`https://gitlab.kitware.com/cmake/cmake/-/issues/24280CMake 3.25.1 Fails to Bootstrap on old openSUSE Linux2023-01-11T17:40:18-05:00Martin VahiCMake 3.25.1 Fails to Bootstrap on old openSUSE LinuxBootstrapping is something that should work also on old machines,
specially for a project like a build system that aims to be
a fancy GNU Make replacement. The build steps:
```
./bootstrap --prefix=/home/mmmv/applications/CMake/v_3_25_...Bootstrapping is something that should work also on old machines,
specially for a project like a build system that aims to be
a fancy GNU Make replacement. The build steps:
```
./bootstrap --prefix=/home/mmmv/applications/CMake/v_3_25_1 --no-qt-gui
# That step worked fine. No errors what so ever.
```
```
gmake
# step gave the following symptoms:
```
The symptoms:
```
[ 23%] Building C object Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/vssh/libssh2.c.o
[ 23%] Building C object Utilities/cmcurl/lib/CMakeFiles/cmcurl.dir/vssh/wolfssh.c.o
[ 23%] Linking C static library libcmcurl.a
[ 23%] Built target cmcurl
[ 23%] Building C object Utilities/cmcurl/CMakeFiles/curltest.dir/curltest.c.o
[ 23%] Linking C executable curltest
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(sha256.c.o): in function `my_sha256_init':
sha256.c:(.text+0x45): undefined reference to `EVP_MD_CTX_new'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(sha256.c.o): in function `Curl_sha256it':
sha256.c:(.text+0x94): undefined reference to `EVP_MD_CTX_new'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: sha256.c:(.text+0xdd): undefined reference to `EVP_MD_CTX_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(sha256.c.o): in function `my_sha256_final':
sha256.c:(.text+0x36): undefined reference to `EVP_MD_CTX_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `ossl_sha256sum':
openssl.c:(.text+0x17b): undefined reference to `EVP_MD_CTX_new'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x1bc): undefined reference to `EVP_MD_CTX_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `ossl_version':
openssl.c:(.text+0x733): undefined reference to `OpenSSL_version'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `ossl_init':
openssl.c:(.text+0xf6c): undefined reference to `OPENSSL_init_ssl'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `cert_stuff':
openssl.c:(.text+0x2243): undefined reference to `OPENSSL_sk_pop_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x26a9): undefined reference to `EVP_PKEY_get_id'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x2da6): undefined reference to `OPENSSL_sk_pop'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x2de3): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x2e0a): undefined reference to `OPENSSL_sk_pop_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `ossl_connect_step1':
openssl.c:(.text+0x31de): undefined reference to `TLS_client_method'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3546): undefined reference to `SSL_CTX_set_options'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x380d): undefined reference to `SSL_CTX_set_ciphersuites'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x38d0): undefined reference to `SSL_CTX_set_post_handshake_auth'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3a48): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3a5c): undefined reference to `OPENSSL_sk_value'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3abb): undefined reference to `OPENSSL_sk_pop_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3b12): undefined reference to `SSL_CTX_load_verify_file'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3b3c): undefined reference to `SSL_CTX_load_verify_dir'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x3c6f): undefined reference to `SSL_CTX_set_keylog_callback'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4109): undefined reference to `OPENSSL_sk_pop_free'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `Curl_ossl_certchain':
openssl.c:(.text+0x418a): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4209): undefined reference to `OPENSSL_sk_value'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x42d0): undefined reference to `X509_get_version'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4427): undefined reference to `X509_get_X509_PUBKEY'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x449b): undefined reference to `X509_get0_extensions'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x44a7): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x44fb): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x450c): undefined reference to `OPENSSL_sk_value'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4581): undefined reference to `X509_get0_notBefore'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x45d1): undefined reference to `X509_get0_notAfter'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4635): undefined reference to `EVP_PKEY_get_id'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4770): undefined reference to `EVP_PKEY_get_bn_param'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4782): undefined reference to `EVP_PKEY_get_bn_param'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4922): undefined reference to `EVP_PKEY_get_bn_param'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4934): undefined reference to `EVP_PKEY_get_bn_param'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4946): undefined reference to `EVP_PKEY_get_bn_param'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o):openssl.c:(.text+0x4958): more undefined references to `EVP_PKEY_get_bn_param' follow
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `Curl_ossl_verifyhost':
openssl.c:(.text+0x4ea7): undefined reference to `OPENSSL_sk_num'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4ef2): undefined reference to `OPENSSL_sk_value'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x4f0e): undefined reference to `ASN1_STRING_get0_data'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x523c): undefined reference to `ASN1_STRING_get0_data'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: lib/libcmcurl.a(openssl.c.o): in function `servercert':
openssl.c:(.text+0x52ec): undefined reference to `SSL_get1_peer_certificate'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x53f7): undefined reference to `X509_get0_notBefore'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x5446): undefined reference to `X509_get0_notAfter'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x55e9): undefined reference to `X509_get_X509_PUBKEY'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x5627): undefined reference to `X509_get_X509_PUBKEY'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x5d79): undefined reference to `SSL_get1_peer_certificate'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x5d99): undefined reference to `OPENSSL_sk_value'
/usr/lib64/gcc/x86_64-suse-linux/4.8/../../../../x86_64-suse-linux/bin/ld: openssl.c:(.text+0x5dc0): undefined reference to `OPENSSL_sk_num'
collect2: error: ld returned 1 exit status
Utilities/cmcurl/CMakeFiles/curltest.dir/build.make:101: recipe for target 'Utilities/cmcurl/curltest' failed
gmake[2]: *** [Utilities/cmcurl/curltest] Error 1
CMakeFiles/Makefile2:1873: recipe for target 'Utilities/cmcurl/CMakeFiles/curltest.dir/all' failed
gmake[1]: *** [Utilities/cmcurl/CMakeFiles/curltest.dir/all] Error 2
Makefile:165: recipe for target 'all' failed
gmake: *** [all] Error 2
mmmv@terminal01:~/tmp_/kompil/cmake-3.25.1$ uname -a
Linux terminal01 4.4.126-48-default #1 SMP Sat Apr 7 05:22:50 UTC 2018 (f24992c) x86_64 x86_64 x86_64 GNU/Linux
mmmv@terminal01:~/tmp_/kompil/cmake-3.25.1$ gcc -version
gcc: error: unrecognized command line option ‘-version’
gcc: fatal error: no input files
compilation terminated.
mmmv@terminal01:~/tmp_/kompil/cmake-3.25.1$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-4.8 --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 4.8.5 (SUSE Linux)
mmmv@terminal01:~/tmp_/kompil/cmake-3.25.1$ ls
Auxiliary CMakeGraphVizOptions.cmake CompileFlags.cmake Templates
Bootstrap.cmk CMakeLists.txt Copyright.txt Testing
CMake.DeveloperReference.HTML.qs CMakeLogo.gif DartConfig.cmake Tests
CMake.Dialogs.QtGUI.qs CONTRIBUTING.rst DartConfiguration.tcl Utilities
CMake.Documentation.SphinxHTML.qs CPackConfig.cmake Help bin
CMake.qs CPackSourceConfig.cmake Licenses bootstrap
CMakeCPack.cmake CTestConfig.cmake Makefile cmake_install.cmake
CMakeCPackOptions.cmake CTestCustom.cmake Modules cmake_uninstall.cmake
CMakeCPackOptions.cmake.in CTestCustom.cmake.in Packaging cmake_uninstall.cmake.in
CMakeCache.txt CTestScript.cmake README.rst configure
CMakeFiles CTestTestfile.cmake Source doxygen.config
mmmv@terminal01:~/tmp_/kompil/cmake-3.25.1$
```https://gitlab.kitware.com/cmake/cmake/-/issues/24276bootstrap cmake in infinite loop on CentOS5-32bit2023-01-11T18:41:42-05:00Axel K. Reinholdbootstrap cmake in infinite loop on CentOS5-32biti need a fairly new cmake on an old CentOS-5-32bit installation.
bootstrap cmake-3.22.6 compiles fine with gcc 9.3.0 and last CentOS5-glibc:
```
Name : glibc Relocations: (not relocatable)
Version ...i need a fairly new cmake on an old CentOS-5-32bit installation.
bootstrap cmake-3.22.6 compiles fine with gcc 9.3.0 and last CentOS5-glibc:
```
Name : glibc Relocations: (not relocatable)
Version : 2.5 Vendor: CentOS
Release : 123.el5_11.3 Build Date: Mon 17 Aug 2015 06:32:38 PM CEST
```
bootstrapped cmake can not build cmake - it goes into endless loop
trace ends with:
```
cmake-3.22.6/Modules/CMakeDetermineCompilerId.cmake(828):
file(STRINGS cmake-3.22.6/CMakeFiles/3.22.6/CompilerIdC/a.out
CMAKE_C_COMPILER_ID_STRINGS LIMIT_COUNT 38 REGEX .?I.?N.?F.?O.?:.?[A-Za-z0-9_]+\[[^]]*\] )
```
i tracked down the loop the while-loop in cmFileCommand.cxx does never terminate:
```c++
// Parse strings out of the file.
int output_size = 0;
std::vector<std::string> strings;
std::string s;
while ((!limit_count || strings.size() < limit_count) &&
(limit_input < 0 || static_cast<int>(fin.tellg()) < limit_input) &&
fin) {
```
... never ends
can you help or is 32-bit no more possible?https://gitlab.kitware.com/cmake/cmake/-/issues/24196Android: CMake 3.25.0 sets LINUX true2022-12-06T08:39:31-05:00Robert NevalaAndroid: CMake 3.25.0 sets LINUX trueSetting global variable LINUX in CMake 3.25.0 is causing problems with Android builds on OSX
CMake 3.25.0 considers ANDROID build on OSX a LINUX target due to the compiler in the android toolchain (`__linux__`).
With build systems that ...Setting global variable LINUX in CMake 3.25.0 is causing problems with Android builds on OSX
CMake 3.25.0 considers ANDROID build on OSX a LINUX target due to the compiler in the android toolchain (`__linux__`).
With build systems that handle Linux and Android build targets separately this will cause a lot of problems.
Added following to showcase the problem:
```
message("#### before project() LINUX = ${LINUX}")
project(${PROJ_NAME})
message("#### after project() LINUX = ${LINUX}")
```
Outputs the following:
```
C/C++: debug|arm64-v8a :#### before project() LINUX =
C/C++: debug|arm64-v8a :#### after project() LINUX = 1
```
Starting to set this flag now is a bit odd choice as many build systems have already built handling for this case.
In our case we have a lot of logic using LINUX & ANDROID separately.3.25.1Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/24126FindPython: Query Debian default Python version?2022-11-24T15:58:32-05:00Timo RöhlingFindPython: Query Debian default Python version?By default, `FindPython` and its relatives will choose the newest Python version which is installed on the system. However, during Debian upgrades to a new Python release in the testing and unstable releases, the newest version will some...By default, `FindPython` and its relatives will choose the newest Python version which is installed on the system. However, during Debian upgrades to a new Python release in the testing and unstable releases, the newest version will sometimes be partially broken, which can make CMake-driven builds less reliable.
For this reason, I've carried a small Debian-specific patch in our CMake package for a while now, which queries the current Python default version with `py3versions --default --version` and prefers that version if none is requested.
As far as I can tell, it works fine and causes no regressions, so I'm considering opening a merge request for this. As this addresses a relatively minor problem for a limited set of users, I wanted to ask for opinions first, though.https://gitlab.kitware.com/cmake/cmake/-/issues/23872Pre-compiled Linux x86_64 crashes on latest Alpine Linux2022-10-05T09:28:14-04:00Björn HendriksPre-compiled Linux x86_64 crashes on latest Alpine LinuxRunning the pre-compiled CMake 3.24.1 (from `cmake-3.24.1-linux-x86_64.tar.gz`) crashes immediately with a segfault on the latest Alpine 3.16.2 run in a Docker container based on `alpine:latest` image.
This happens even with an empty `C...Running the pre-compiled CMake 3.24.1 (from `cmake-3.24.1-linux-x86_64.tar.gz`) crashes immediately with a segfault on the latest Alpine 3.16.2 run in a Docker container based on `alpine:latest` image.
This happens even with an empty `CMakeLists.txt` immediately after warning about the missing `project()` command. Calling CMake with option `--version` works as expected.
I've also tried it with older pre-compiled CMake versions:
* 3.23.3 --> same problem
* 3.22.6, 3.21.7, 3.19.2 --> work as expected3.23.4Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/23840Set LINUX variable when running on a Linux host2022-11-28T14:31:33-05:00Cristian AdamSet LINUX variable when running on a Linux hostLinux nowadays is a pretty common development environment and CMake users expect something like:
```cmake
if (WIN32) ✅
if (APPLE) ✅
if (LINUX) ❌
```
to work.
See ([complaint](https://twitter.com/timur_audio/status/1557339369463234563)...Linux nowadays is a pretty common development environment and CMake users expect something like:
```cmake
if (WIN32) ✅
if (APPLE) ✅
if (LINUX) ❌
```
to work.
See ([complaint](https://twitter.com/timur_audio/status/1557339369463234563)):
![linux-cmake](/uploads/1072e90b4748296d01aea0439a6bcf8e/linux-cmake.png)https://gitlab.kitware.com/cmake/cmake/-/issues/23597Cross-compiling from linux to apple2022-06-17T11:31:41-04:00Heiko LewinCross-compiling from linux to appleHello!
Cross-compiling from linux to apple-products runs into the issue https://gitlab.kitware.com/cmake/cmake/-/issues/19211 at least for iOS targets.
The problem seems to be that the .app-bundle handling does not take place if the _c...Hello!
Cross-compiling from linux to apple-products runs into the issue https://gitlab.kitware.com/cmake/cmake/-/issues/19211 at least for iOS targets.
The problem seems to be that the .app-bundle handling does not take place if the _compiling_ host isn't apple.
I could fix the problem with the little patch below, simply removing the `#if defined(__APPLE__)`.
Another way that could work, I guess, is checking if the compiler-target (CMAKE_SYSTEM_NAME) is something apple-ish - but I didn't test that nor did I look at the rest of the cmake-sources if that would make sense.
[ConsiderAppBundles.patch](/uploads/73cf72a1a8df782ac5688b1d775a9954/ConsiderAppBundles.patch)
PS: This is with cmake 3.23.2 btw.https://gitlab.kitware.com/cmake/cmake/-/issues/23310InstallRequiredSystemLibraries: Intel oneAPI compilers on Linux2022-03-10T06:43:19-05:00Brad KingInstallRequiredSystemLibraries: Intel oneAPI compilers on LinuxIn the original description of !7057, @attila.krasznahorkay reported the following. I'm moving it to an issue.
---
When using
```cmake
cmake_minimum_required( VERSION 3.10 )
project( IntelRuntimeInstallTest LANGUAGES C CXX VERSION 0....In the original description of !7057, @attila.krasznahorkay reported the following. I'm moving it to an issue.
---
When using
```cmake
cmake_minimum_required( VERSION 3.10 )
project( IntelRuntimeInstallTest LANGUAGES C CXX VERSION 0.0.1 )
include( InstallRequiredSystemLibraries )
```
I would see:
<details>
```
[bash][atspot01]:test-build > source /atlas/software/intel/oneapi-2022.1.1/setvars.sh
:: initializing oneAPI environment ...
bash: BASH_VERSION = 4.4.20(1)-release
args: Using "$@" for setvars.sh arguments:
:: advisor -- latest
:: ccl -- latest
:: compiler -- latest
:: dal -- latest
:: debugger -- latest
:: dev-utilities -- latest
:: dnnl -- latest
:: dpcpp-ct -- latest
:: dpl -- latest
:: intelpython -- latest
:: ipp -- latest
:: ippcp -- latest
:: ipp -- latest
:: mkl -- latest
:: mpi -- latest
:: tbb -- latest
:: vpl -- latest
:: vtune -- latest
:: oneAPI environment initialized ::
[bash][atspot01]:test-build > export CC=icx
[bash][atspot01]:test-build > export CXX=icpx
[bash][atspot01]:test-build > /atlas/software/cmake/3.22.2/x86_64-ubuntu1804-gcc7-opt/bin/cmake ../source/
-- The C compiler identification is IntelLLVM 2022.0.0
-- The CXX compiler identification is IntelLLVM 2022.0.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /atlas/software/intel/oneapi-2022.1.1/compiler/2022.0.1/linux/bin/icx - 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: /atlas/software/intel/oneapi-2022.1.1/compiler/2022.0.1/linux/bin/icpx - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning at /atlas/software/cmake/3.22.2/x86_64-ubuntu1804-gcc7-opt/share/cmake-3.22/Modules/InstallRequiredSystemLibraries.cmake:732 (message):
system runtime library file does not exist: 'NOT-FOUND/libchkp.so'
Call Stack (most recent call first):
CMakeLists.txt:4 (include)
CMake Warning at /atlas/software/cmake/3.22.2/x86_64-ubuntu1804-gcc7-opt/share/cmake-3.22/Modules/InstallRequiredSystemLibraries.cmake:732 (message):
system runtime library file does not exist: 'NOT-FOUND/libcilkrts.so'
Call Stack (most recent call first):
CMakeLists.txt:4 (include)
CMake Warning at /atlas/software/cmake/3.22.2/x86_64-ubuntu1804-gcc7-opt/share/cmake-3.22/Modules/InstallRequiredSystemLibraries.cmake:732 (message):
system runtime library file does not exist: 'NOT-FOUND/libcilkrts.so.5'
Call Stack (most recent call first):
CMakeLists.txt:4 (include)
...
```
</details>
With the change proposed in !7057, the warnings become:
<details>
```
[bash][atspot01]:test-build > ../install/bin/cmake ../source/
-- The C compiler identification is IntelLLVM 2022.0.0
-- The CXX compiler identification is IntelLLVM 2022.0.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /atlas/software/intel/oneapi-2022.1.1/compiler/2022.0.1/linux/bin/icx - 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: /atlas/software/intel/oneapi-2022.1.1/compiler/2022.0.1/linux/bin/icpx - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning at /home/krasznaa/ATLAS/projects/cmake-psxe/install/share/cmake-3.23/Modules/InstallRequiredSystemLibraries.cmake:733 (message):
system runtime library file does not exist:
'/atlas/software/intel/oneapi-2022.1.1/compiler/2022.0.1/linux/bin/../compiler/lib/intel64_lin/libcilkrts.so'
Call Stack (most recent call first):
CMakeLists.txt:4 (include)
CMake Warning at /home/krasznaa/ATLAS/projects/cmake-psxe/install/share/cmake-3.23/Modules/InstallRequiredSystemLibraries.cmake:733 (message):
system runtime library file does not exist:
'/atlas/software/intel/oneapi-2022.1.1/compiler/2022.0.1/linux/bin/../compiler/lib/intel64_lin/libcilkrts.so.5'
Call Stack (most recent call first):
CMakeLists.txt:4 (include)
...
```
</details>
The list of libraries will also need to be revised in a further step.
Note that the previous path **is** correct for PSXE 2019. For instance:
<details>
```
[bash][atspot01]:build > source /cvmfs/projects.cern.ch/intelsw/psxe/linux/19-all-setup.sh
---------- PLEASE NOTICE! ----------
Intel Parallel Studio will be discontinued in the near future
We recommend to switch to Intel oneAPI
---------- NOTICE: PS 2019 installed ------------
Setting up Parallel Studio 2019 environment for 'intel64'. Accepted arguments: intel64, ia32
Intel(R) Parallel Studio XE 2019 Update 4 for Linux*
Copyright (C) 2009-2019 Intel Corporation. All rights reserved.
If you wish to use Intel Amplifier XE with hardware counters, please first compile and run
the sep drivers (as root):
https://software.intel.com/en-us/sep_driver
[bash][atspot01]:build > export CC=icc
[bash][atspot01]:build > export CXX=icpc
[bash][atspot01]:build > /atlas/software/cmake/3.22.2/x86_64-ubuntu1804-gcc7-opt/bin/cmake ../source/
-- The C compiler identification is Intel 19.0.5.20190815
-- The CXX compiler identification is Intel 19.0.5.20190815
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /cvmfs/projects.cern.ch/intelsw/psxe/linux/x86_64/2019/compilers_and_libraries_2019.5.281/linux/bin/intel64/icc - 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: /cvmfs/projects.cern.ch/intelsw/psxe/linux/x86_64/2019/compilers_and_libraries_2019.5.281/linux/bin/intel64/icpc - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
CMake Warning at /atlas/software/cmake/3.22.2/x86_64-ubuntu1804-gcc7-opt/share/cmake-3.22/Modules/InstallRequiredSystemLibraries.cmake:732 (message):
system runtime library file does not exist:
'/cvmfs/projects.cern.ch/intelsw/psxe/linux/x86_64/2019/compilers_and_libraries_2019.5.281/linux/bin/intel64/../../compiler/lib/intel64_lin/libgfxoffload.so'
Call Stack (most recent call first):
CMakeLists.txt:4 (include)
CMake Warning at /atlas/software/cmake/3.22.2/x86_64-ubuntu1804-gcc7-opt/share/cmake-3.22/Modules/InstallRequiredSystemLibraries.cmake:742 (message):
system runtime library file does not exist:
'/cvmfs/projects.cern.ch/intelsw/psxe/linux/x86_64/2019/compilers_and_libraries_2019.5.281/linux/bin/intel64/../../compiler/lib/intel64_lin/irml'
Call Stack (most recent call first):
CMakeLists.txt:4 (include)
-- Configuring done
-- Generating done
-- Build files have been written to: /home/krasznaa/ATLAS/projects/cmake-psxe/build
[bash][atspot01]:build >
```
</details>3.23.0Brad KingBrad Kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/22934file(GET_RUNTIME_DEPENDENCIES...) does not handle linker scripts from TBB2021-11-19T16:39:27-05:00Aron Helserfile(GET_RUNTIME_DEPENDENCIES...) does not handle linker scripts from TBBEncountered in the context of a VTK app using the common superbuild on linux.
TBB binary distributions on linux are distributed with several libraries where `libtbb.so.2` is the real library, and `libtbb.so` is a text file with the cont...Encountered in the context of a VTK app using the common superbuild on linux.
TBB binary distributions on linux are distributed with several libraries where `libtbb.so.2` is the real library, and `libtbb.so` is a text file with the contents
```
INPUT (libtbb.so.2)
```
If I pass this file to `file(GET_RUNTIME_DEPENDENCIES` like so:
```
# Construct a list of libraries already in the application bundle
file(GLOB_RECURSE missing_libs "${CMAKE_INSTALL_PREFIX}/${lib_dest_dir}/*${suffix}")
# Construct a list of the application's runtime dependencies
file(GET_RUNTIME_DEPENDENCIES
....
LIBRARIES ${qt_plugins} ${missing_libs}
)
```
I get a cryptic error:
```
CMake Error at cmake_install.cmake:132 (file):
file Failed to run objdump on:
/home/aron.helser/projects/xxx/sb/build/install/lib/libtbb.so
```
`libtbb.so.2` exists in that directory, so it could be handled. Or a more informative error message, perhaps.https://gitlab.kitware.com/cmake/cmake/-/issues/22896CUDA+FindOpenMP doesn't seem to play nicely with glibc 2.342023-03-07T10:00:21-05:00Robert UnderwoodCUDA+FindOpenMP doesn't seem to play nicely with glibc 2.34Fedora 35 ships glibc 2.34 which includes the functionality previously in libpthread.so instead in glibc and instead provides a stub libpthread. This causes the logic in FindOpenMP.cmake to attempt to search for libpthread.so, not find ...Fedora 35 ships glibc 2.34 which includes the functionality previously in libpthread.so instead in glibc and instead provides a stub libpthread. This causes the logic in FindOpenMP.cmake to attempt to search for libpthread.so, not find it (because it is named libpthread.so.0) and instead find the libpthread.a stub that is also provided in glibc-devel. When this stub is passed to nvcc and seperable compilation, NVCC chokes on this and crashes with an error like: `nvlink fatal : Could not open input file '/usr/lib64/libpthread.a'`. As a temporary workaround, users can pass `-DOpenMP_pthread_LIBRARY=/usr/lib64/libpthread.so.0`, or creating a symlink called `/usr/lib64/libpthread.so` restores compilation.
For example of this bug, [MGARD](https://github.com/CodarCode/MGARD) has this problem. Since there are other problems with building MGARD for Fedora 35, you may wish to use my fork instead `https://github.com/robertu94/mgard` which patches a number of other issues.
List of relevent versions:
```
# using cuda from https://developer.download.nvidia.com/compute/cuda/repos/fedora34/x86_64
[runderwood@voyager MGARD]$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2021 NVIDIA Corporation
Built on Mon_Sep_13_19:13:29_PDT_2021
Cuda compilation tools, release 11.5, V11.5.50
Build cuda_11.5.r11.5/compiler.30411180_0
# using cmake from Fedora 35
[runderwood@voyager MGARD]$ cmake --version
cmake version 3.21.3
# using a default gcc for CXX
[runderwood@voyager Modules]$ /usr/bin/g++ --version
g++ (GCC) 11.2.1 20210728 (Red Hat 11.2.1-1)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# using a backport of GCC copr.fedorainfracloud.org/kwizart/cuda-gcc-10.1 for cuda compilation
[runderwood@voyager MGARD]$ /usr/local/cuda/bin/g++ --version
g++ (GCC) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# using a patched NVCOMP from https://github.com/robertu94/nvcomp
# here are the cmake args to pass to MGARD
'-DBUILD_TESTING=OFF',
'-DCUDA_ARCH_STRING=60',
'-DMGARD_ENABLE_CUDA=ON'
```
>https://gitlab.kitware.com/cmake/cmake/-/issues/22518Attemping building udeb packages with CPack2021-08-06T04:15:15-04:00NykauToutcourtAttemping building udeb packages with CPackI am trying to build udeb packages with CMake/CPack. I see that it works already pretty well for normal Debian packages, but udebs requires, among others, extra fields in the `control` file to produce valid udeb packages. [This page](htt...I am trying to build udeb packages with CMake/CPack. I see that it works already pretty well for normal Debian packages, but udebs requires, among others, extra fields in the `control` file to produce valid udeb packages. [This page](https://d-i.debian.org/doc/internals/ch03.html) instructs to set extra fields `Package-Type: udeb` and `Installer-Menu-Item: 1200` in `control` but I could not find the corresponding CPACK_DEBIAN_PACKAGE_* variables in CMake/CPack documentation.
I assume building udeb is not a feature supported by CPack for now. I would attempt to add the missing bits to achieve it, but I could not find where DEB packages are actually build. I found directory structures and empty files created, as well as lots of variables "moved to parent scope" (whatever that means) at the bottom of `CPackDeb.cmake`, but I did not find what exactly is made of these variables and where this happens.
Can you give me a pointer on where to look?