CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-07-07T10:33:11-04:00https://gitlab.kitware.com/cmake/cmake/-/issues/16943libelf RPATH parsing / install time substitution on Windows2017-07-07T10:33:11-04:00Nils Gladitzlibelf RPATH parsing / install time substitution on WindowsAssuming it is possible it would be nice if the official Windows CMake binaries could be build with libelf support so that RPATH install time substitution could be used instead of re-linking (which currently prohibits use of Ninja) in a ...Assuming it is possible it would be nice if the official Windows CMake binaries could be build with libelf support so that RPATH install time substitution could be used instead of re-linking (which currently prohibits use of Ninja) in a cross-compile setup targeting Linux.https://gitlab.kitware.com/cmake/cmake/-/issues/16921Cannot set debian package dependency after include(CPack)2017-05-25T17:54:29-04:00Peter-Frank SpierenburgCannot set debian package dependency after include(CPack)I am using Ubuntu 16.04 and CMake 3.5
My goal is to produce two debian packages, a -lib package that contains a shared library, and a -dev package that contains the headers and depends on the -lib.
I originally tried to use the `cp...I am using Ubuntu 16.04 and CMake 3.5
My goal is to produce two debian packages, a -lib package that contains a shared library, and a -dev package that contains the headers and depends on the -lib.
I originally tried to use the `cpack_add_component` defined by CPack, but couldn't make it work. I've posted about that on StackOverflow: https://stackoverflow.com/questions/44166400/cmake-cpack-doesnt-recognize-inter-component-dependencies
As an alternative I decided instead to try using `CPACK_DEBIAN_<component>_PACKAGE_DEPENDS`. Here is my `CMakeLists.txt` file:
```cmake
cmake_minimum_required(VERSION 3.5)
project(libmy)
include_directories(include)
add_library(my SHARED src/main/my.c)
install(TARGETS my
DESTINATION /usr/local/lib/
COMPONENT lib)
install(FILES include/my.h
DESTINATION /usr/local/include
COMPONENT dev)
set(CPACK_GENERATOR "DEB")
set(CPACK_DEB_COMPONENT_INSTALL ON)
set(CPACK_DEBIAN_PACKAGE_MAINTAINER "Me")
include(CPack)
set(CPACK_DEBIAN_DEV_PACKAGE_DEPENDS "${CPACK_PACKAGE_NAME}-lib (=${CPACK_PACKAGE_VERSION})")
```
This seems to fall down on the order of the `include(CPack)` and the `set(CPACK_DEBIAN_DEV_PACKAGE_DEPENDS "${CPACK_PACKAGE_NAME}-lib (=${CPACK_PACKAGE_VERSION})")`
In the order listed above, CPack ignores the `CPACK_DEBIAN_DEV_PACKAGE_DEPENDS` directive entirely, not adding an appropriate entry to the control file.
However, if I switch the order, I get an entry that has no `${CPACK_PACKAGE_NAME}` or `${CPACK_PACKAGE_VERSION}`.https://gitlab.kitware.com/cmake/cmake/-/issues/16919Do not emit -isystem for INSTALL_INCLUDE_PATH2018-08-30T11:11:54-04:00Demi Marie ObenourDo not emit -isystem for INSTALL_INCLUDE_PATHWhen running mingw64-cmake on my Fedora 26 system, CMake generates -isystem flags pointing to the value of `${INCLUDE_INSTALL_DIR}`, which in this case happens to be `/usr/x86_64-w64-mingw32/sys-root/mingw/include`. This causes compilat...When running mingw64-cmake on my Fedora 26 system, CMake generates -isystem flags pointing to the value of `${INCLUDE_INSTALL_DIR}`, which in this case happens to be `/usr/x86_64-w64-mingw32/sys-root/mingw/include`. This causes compilation to fail with:
In file included from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/ext/string_conversions.h:41:0,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/bits/basic_string.h:6157,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/string:52,
from /usr/x86_64-w64-mingw32/sys-oot/mingw/include/boost/test/utils/basic_cstring/bcs_char_traits.hpp:25,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/utils/basic_cstring/basic_cstring.hpp:21,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/detail/global_typedef.hpp:15,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/tree/observer.hpp:17,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/unit_test_log.hpp:18,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/tools/old/impl.hpp:19,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/test_tools.hpp:46,
from /usr/x86_64-w64-mingw32/sys-root/mingw/include/boost/test/unit_test.hpp:18,
from /home/dobenour/repos/SlipRock/src/test.cpp:16:
/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
#include_next <stdlib.h>
The culprit is that CMake generates `-isystem` flags pointing to `INCLUDE_INSTALL_DIR`, when it should use plain `-I`.
Tested with version 3.8.1 from Fedora. There was a [GCC bug] about this behavior on GCC’s part, which was closed as WONTFIX.
[GCC bug]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129https://gitlab.kitware.com/cmake/cmake/-/issues/16871FindMPI can't find openmpi libraries on Fedora252017-07-30T06:33:37-04:00Michael ClerxFindMPI can't find openmpi libraries on Fedora25Trying to compile something using cmake and OpenMPI on Fedora 25, but get `missing MPI_C_LIBRARIES MPI_C_INCLUDE_PATH` even though I can see the libraries and header files myself. Has this been tested on Fedora and am I doing something w...Trying to compile something using cmake and OpenMPI on Fedora 25, but get `missing MPI_C_LIBRARIES MPI_C_INCLUDE_PATH` even though I can see the libraries and header files myself. Has this been tested on Fedora and am I doing something wrong, or is it a bug in the implementation?https://gitlab.kitware.com/cmake/cmake/-/issues/16857Is it normal after a build, around 200MB memory is occupied(Linux system)2017-05-09T17:02:56-04:00jenniferIs it normal after a build, around 200MB memory is occupied(Linux system)I use cmake 3.5.1, the linux machine used memory grows up after each build. Is that normal?
Because each time build the app, around 200 MB memory used, sooner or later memory will be use out.I use cmake 3.5.1, the linux machine used memory grows up after each build. Is that normal?
Because each time build the app, around 200 MB memory used, sooner or later memory will be use out.https://gitlab.kitware.com/cmake/cmake/-/issues/16825The subcommands RPATH_CHANGE, RPATH_CHECK and RPATH_REMOVE are not documented2023-11-14T03:51:37-05:00YannThe subcommands RPATH_CHANGE, RPATH_CHECK and RPATH_REMOVE are not documentedThe subcommands RPATH_CHANGE, RPATH_CHECK and RPATH_REMOVE are not documented.
Checked on cmake 3.6.2The subcommands RPATH_CHANGE, RPATH_CHECK and RPATH_REMOVE are not documented.
Checked on cmake 3.6.2https://gitlab.kitware.com/cmake/cmake/-/issues/16809Request: Update Visual Studio generators with Linux X-platform project genera...2022-03-30T15:30:37-04:00Robert BielikRequest: Update Visual Studio generators with Linux X-platform project generationhttps://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/https://blogs.msdn.microsoft.com/vcblog/2016/03/30/visual-c-for-linux-development/https://gitlab.kitware.com/cmake/cmake/-/issues/16769sunCC on debian2017-08-15T09:20:48-04:00Marc GlissesunCC on debianHello,
I am using oracle developer studio 12.6 beta on a debian testing x86_64 system. I added cc.defaults and CC.defaults files in $studio/lib/compilers/etc/config which contain -Wp,-I/usr/include/x86_64-linux-gnu, and the compiler see...Hello,
I am using oracle developer studio 12.6 beta on a debian testing x86_64 system. I added cc.defaults and CC.defaults files in $studio/lib/compilers/etc/config which contain -Wp,-I/usr/include/x86_64-linux-gnu, and the compiler seems to work on a few simple tests (in particular it can find headers in /usr/include/x86_64-linux-gnu when I compile without any specific flags, suncc -c test.c). cmake does identify the compiler as SunPro 5.15.0. However, cmake fails to search for headers in that directory (it searches in many places that do not exist like /usr/include/w32api, /usr/pkg/include, /opt/csw/include, /usr/openwin/include, etc).
I tested with a 1-line CMakeLists.txt: find_path(FOO gmp.h)
and then, from different subdirectories, compared CC=gcc cmake .. and CC=suncc cmake .., and gmp.h was only found in the first case.
I tried using
list(APPEND CMAKE_SYSTEM_INCLUDE_PATH /usr/include/x86_64-linux-gnu)
list(APPEND CMAKE_SYSTEM_LIBRARY_PATH /usr/lib/x86_64-linux-gnu)
but that is not just used for searching files, cmake also passes corresponding -I and -L flags to the compiler, which breaks things (the order in which system paths are searched is very sensitive).
I believe that cmake should know that on debian, whatever the compiler, those 2 paths exist and contain important stuff... (the compiler is still relevant in that it determines the target, and thus which triplet to append to /usr/{include,lib})
An alternative would be to stop looking for files all over the place, trying to duplicate compiler logic, and rely on something like try_compile (like autoconf).https://gitlab.kitware.com/cmake/cmake/-/issues/16721CPACK_RPM_DEBUGINFO_PACKAGE =on + CPACK_RPM_${COMPONENT}_DEBUGINFO_PACKAGE=OF...2017-10-13T13:17:55-04:00Daniel BlackCPACK_RPM_DEBUGINFO_PACKAGE =on + CPACK_RPM_${COMPONENT}_DEBUGINFO_PACKAGE=OFF still builds debuginfo for componentsmall feature request. Should be possible to disable a small number of components.small feature request. Should be possible to disable a small number of components.Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/16705cpack: wrong directory permissions of automatically created directories in d...2017-10-13T13:17:55-04:00Bernicpack: wrong directory permissions of automatically created directories in deb build.When building a deb-package the permissions of directories should be 755 according do debian standard but they are 770 if the directories are automatically added. This includes even directories, that are part of the ${CMAKE_INSTALL_PREFIX}.When building a deb-package the permissions of directories should be 755 according do debian standard but they are 770 if the directories are automatically added. This includes even directories, that are part of the ${CMAKE_INSTALL_PREFIX}.https://gitlab.kitware.com/cmake/cmake/-/issues/16650mixing root-owned with user-owned files in the same place with the install_ma...2020-04-21T15:01:40-04:00Maurizio Paolinimixing root-owned with user-owned files in the same place with the install_manifest.txt fileOn linux systems.
Perhaps this is not considered an issue, however I wish to report it anyway, since it might produce unexpected problems.
Often the cmake build directory is the same as the source directory and will contain compiled fi...On linux systems.
Perhaps this is not considered an issue, however I wish to report it anyway, since it might produce unexpected problems.
Often the cmake build directory is the same as the source directory and will contain compiled files owned by the user.
However at install time a new file is created named install_manifest.txt in the build directory and owned by root. Under some
circumstances (e.g. when the user home is NFS mounted with "root-squashing", this is not allowed and will cause termination
of the install process with an error.
Or, as a different scenario, some authomatic tool that deals with user files (e.g. a backup script) could have unexpected behaviour
with files that it cannot remove.
Is there a specific reason why the install_manifest.txt is *not* created with user ownership, e.g. inheriting the ownership from the
parent directory? Being in the install stage, this should be possible, or at least as possible as creating a root-owned file inside a user-owned
directory.
[sorry, this is formatted badly, but I do not know how to disable markup]
Example case:
```
$ git clone git@git.kde.org:kig
$ cd kig
$ cmake . -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull -DPLUGIN_INSTALL_DIR:PATH=/usr/lib/qt5/plugins
$ make
$ su
Password: ***
# make install
# exit
$ ls -l | grep root
-rw-r--r-- 1 root root 18579 14 feb 23.51 install_manifest.txt
```https://gitlab.kitware.com/cmake/cmake/-/issues/16562CPack: DEB: Create src and debuginfo packages2017-10-13T13:17:55-04:00Egor ShokhinCPack: DEB: Create src and debuginfo packagesHi, Is there solution for this problem?
I would like to help to solve this issue, because I need this functionality to work properly in my project. Can you suggest something, which way to look at?Hi, Is there solution for this problem?
I would like to help to solve this issue, because I need this functionality to work properly in my project. Can you suggest something, which way to look at?https://gitlab.kitware.com/cmake/cmake/-/issues/16296cmState::Directory::ComputeRelativePathTopBinary() should not execute Windows...2017-10-13T13:17:55-04:00davidltcmState::Directory::ComputeRelativePathTopBinary() should not execute Windows specific bits on anything else (e.g. Linux)We are bootstrapping Linux distribution on a new architecture (riscv64) and we recently added a build of CMake. At this point our rootfs boots with "root" account and HOME is "/". We are building RPM based Fedora distribution. _rpm-build...We are bootstrapping Linux distribution on a new architecture (riscv64) and we recently added a build of CMake. At this point our rootfs boots with "root" account and HOME is "/". We are building RPM based Fedora distribution. _rpm-build_ defines: `%_topdir %{getenv:HOME}/rpmbuild` and in this case we get `//rpmbuild` as `%_topdir`.
The following Windows specific bit is triggered in `cmState::Directory::ComputeRelativePathTopBinary()`
```
756 // The current working directory on Windows cannot be a network
757 // path. Therefore relative paths cannot work when the binary tree
758 // is a network path.
759 if (result.size() < 2 || result.substr(0, 2) != "//") {
760 this->DirectoryState->RelativePathTopBinary = result;
761 } else {
762 this->DirectoryState->RelativePathTopBinary = "";
763 }
```
CMake ends up calling Make targets with prefixes `//rpmbuild/BUILD/<package_name>/build/<make_rule_name>`.
E.g.,
```
make -f CMakeFiles/Makefile2 //rpmbuild/BUILD/nss-pem-1.0.2/build/all
make[1]: Entering directory '/rpmbuild/BUILD/nss-pem-1.0.2/build'
make[1]: *** No rule to make target '//rpmbuild/BUILD/nss-pem-1.0.2/build/all'. Stop.
```
The problem is that then it cannot find the rule.
If one sets `--define "_topdir /rpmbuild"` for _rpm-build_ it makes CMake work.
TL;DR Windows specific bit should be protected by Windows specific guards.https://gitlab.kitware.com/cmake/cmake/-/issues/16272CPACK_DEBIAN_PACKAGE_DESCRIPTION doesn't default to CPACK_PACKAGE_DESCRIPTION...2017-10-13T13:17:56-04:00Ghost UserCPACK_DEBIAN_PACKAGE_DESCRIPTION doesn't default to CPACK_PACKAGE_DESCRIPTION_FILEWith CPackDeb, if not explicitly set, the variable `CPACK_DEBIAN_PACKAGE_DESCRIPTION` defaults to `CPACK_PACKAGE_DESCRIPTION_SUMMARY` and not to
`CPACK_PACKAGE_DESCRIPTION_FILE`.
This doesn't match the CPackRPM behavior where `CPACK_RP...With CPackDeb, if not explicitly set, the variable `CPACK_DEBIAN_PACKAGE_DESCRIPTION` defaults to `CPACK_PACKAGE_DESCRIPTION_SUMMARY` and not to
`CPACK_PACKAGE_DESCRIPTION_FILE`.
This doesn't match the CPackRPM behavior where `CPACK_RPM_PACKAGE_DESCRIPTION` does default to `CPACK_PACKAGE_DESCRIPTION_FILE`.
See also this old email thread, where a workaround is described and the OP is encouraged to open a bug report:
http://cmake.3232098.n2.nabble.com/CPACK-PACKAGE-DESCRIPTION-FILE-for-debian-td6951145.html
IMHO, a more expected behavior of `CPACK_DEBIAN_PACKAGE_DESCRIPTION` would be to also default to `CPACK_PACKAGE_DESCRIPTION_FILE` (if set). `CPACK_PACKAGE_DESCRIPTION_SUMMARY` could be used as fallback default if both `CPACK_DEBIAN_DESCRIPTION` and `CPACK_PACKAGE_DESCRIPTION_FILE` are unset.Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/15618HDF5 headers have migrated in linux/debian/sid -- FindHDF5.cmake doesn't dete...2017-10-13T13:17:56-04:00Kitware RobotHDF5 headers have migrated in linux/debian/sid -- FindHDF5.cmake doesn't detect themThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15618). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15618). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15217CPack make wrong dependencies between components2017-10-13T13:17:56-04:00Kitware RobotCPack make wrong dependencies between componentsThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15217). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15217). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15163CPack: wrong permissions on base files with nonstandard umask setting2018-04-28T09:16:21-04:00Kitware RobotCPack: wrong permissions on base files with nonstandard umask settingThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15163). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15163). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15124CPack doesn't package static libraries when CPACK_RPM_COMPONENT_INSTALL is on2018-04-28T09:16:21-04:00Kitware RobotCPack doesn't package static libraries when CPACK_RPM_COMPONENT_INSTALL is onThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15124). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15124). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15007FindImageMagick detection broken with multi-arch imagemagick, need CFLAGS fro...2021-08-13T05:35:57-04:00Kitware RobotFindImageMagick detection broken with multi-arch imagemagick, need CFLAGS from pkgconfigThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15007). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15007). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/14609cmake -E copy and cmake -E copy_directory commands need an option to NOT foll...2024-03-28T04:51:50-04:00Kitware Robotcmake -E copy and cmake -E copy_directory commands need an option to NOT follow symlinks on LinuxThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14609). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=14609). Further discussion may take place here.