CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2017-08-15T09:20:48-04:00https://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/16717CPACK_RPM - CPACK_RPM_DEBUGINFO_PACKAGE - cmake-3.8.latest fails to generate ...2017-04-03T23:02:56-04:00Daniel BlackCPACK_RPM - CPACK_RPM_DEBUGINFO_PACKAGE - cmake-3.8.latest fails to generate debuginfo packages where 3.7.2 did```
cmake --version
cmake version 3.8.20170312-gce070
cmake ../mariadb-server/ -DRPM=fedora | tee /tmp/cmake-new-c.txt && make VERBOSE=1 -j32 --output-sync=target package
...
CMake Warning (dev) at /usr/local/cmake-3.8.20170312-g...```
cmake --version
cmake version 3.8.20170312-gce070
cmake ../mariadb-server/ -DRPM=fedora | tee /tmp/cmake-new-c.txt && make VERBOSE=1 -j32 --output-sync=target package
...
CMake Warning (dev) at /usr/local/cmake-3.8.20170312-gce070-Linux-x86_64/share/cmake-3.8/Modules/CPackRPM.cmake:2229 (message):
CPackRPM:Warning: debuginfo package was requested but will not be generated
as no source files were found! Component: 'test'.
...
ls *rpm
MariaDB-5.5.55-fedora-x86_64-common.rpm MariaDB-5.5.55-fedora-x86_64-shared.rpm MariaDB-server-5.5.55-1.fc25.x86_64.rpm
MariaDB-5.5.55-fedora-x86_64-devel.rpm MariaDB-client-5.5.55-1.fc25.x86_64.rpm MariaDB-test-5.5.55-1.fc25.x86_64.rpm
```
from: https://github.com/grooverdan/mariadb-server/tree/5.5-MDEV-4646-rpm-debug-symbols
[build-new-c.txt](/uploads/34204ba28dc8b5e88ac87811c650ccad/build-new-c.txt)3.8.0Domen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/16715CPACK_RPM - CPACK_RPM_DEBUGINFO_PACKAGE =on causes CPACK_PACKAGE_FILE_NAME t...2017-04-28T03:38:11-04:00Daniel BlackCPACK_RPM - CPACK_RPM_DEBUGINFO_PACKAGE =on causes CPACK_PACKAGE_FILE_NAME to be ignoredWith:
`SET(CPACK_PACKAGE_FILE_NAME "${CPACK_RPM_PACKAGE_NAME}-${VERSION}-${RPM}-${CMAKE_SYSTEM_PROCESSOR}")`
and
`SET(CPACK_RPM_${COMPONENT_UPPER}_DEBUGINFO_PACKAGE ON)`
for the non common/devel/shared components caused So ...With:
`SET(CPACK_PACKAGE_FILE_NAME "${CPACK_RPM_PACKAGE_NAME}-${VERSION}-${RPM}-${CMAKE_SYSTEM_PROCESSOR}")`
and
`SET(CPACK_RPM_${COMPONENT_UPPER}_DEBUGINFO_PACKAGE ON)`
for the non common/devel/shared components caused So the CPACK_RPM_PACKAGE_NAME was ignored for server,client and test.
```
MariaDB-5.5.55-fedora-x86_64-common.rpm
MariaDB-5.5.55-fedora-x86_64-devel.rpm
MariaDB-5.5.55-fedora-x86_64-shared.rpm
MariaDB-client-5.5.55-1.fc25.x86_64.rpm
MariaDB-client-debuginfo-5.5.55-1.fc25.x86_64.rpm
MariaDB-server-5.5.55-1.fc25.x86_64.rpm
MariaDB-server-debuginfo-5.5.55-1.fc25.x86_64.rpm
MariaDB-test-5.5.55-1.fc25.x86_64.rpm
MariaDB-test-debuginfo-5.5.55-1.fc25.x86_64.rpm
```
Also as a feature request - having a CPACK_DEBUGIFNO_PACKAGE_FILE_NAME for setting the debug package RPMs would be nice to make these consistent. Perhaps appending "-debuginfo" to CPACK_RPM_PACKAGE_NAME and using the resulting CPACK_PACKAGE_FILE_NAME value for the as the resulting name for debuginfo packages as default.
cmake version 3.7.2
ref: https://github.com/grooverdan/mariadb-server/blob/5.5-MDEV-4646-rpm-debug-symbols/cmake/cpack_rpm.cmakeDomen VrankarDomen Vrankarhttps://gitlab.kitware.com/cmake/cmake/-/issues/16710cmake tests fail with new rpm2017-05-03T19:30:24-04:00Orion Poplawskicmake tests fail with new rpmOn Fri, 2017-03-10 at 11:51 -0700, Orion Poplawski wrote:
> A cmake build test is failing with the jump in rpm from 4.13.0.1-3.fc26 >
> 4.13.0.1-7.fc27
>
> The upshot appears to be that an rpm generated by cmake's cpack utility has
> ad...On Fri, 2017-03-10 at 11:51 -0700, Orion Poplawski wrote:
> A cmake build test is failing with the jump in rpm from 4.13.0.1-3.fc26 >
> 4.13.0.1-7.fc27
>
> The upshot appears to be that an rpm generated by cmake's cpack utility has
> additional files in it, e.g.:
>
> /usr/lib/.build-id
> /usr/lib/.build-id/5d
> /usr/lib/.build-id/5d/a319a6e633c6da1cd98aafe3744adf664d529a
>
> are these to be expected, or are these supposed to be elsewhere?
Good you have a sanity check for this. But those are (now) expected to
be there. This is because of the new default setting of the
_build_id_links macro (compat):
```
# Defines how and if build_id links are generated for ELF files.
# The following settings are supported:
#
# - none
# No build_id links are generated.
#
# - alldebug
# build_id links are generated only when the __debug_package global is
# defined. This will generate build_id links in the -debuginfo package
# for both the main file as /usr/lib/debug/.build-id/xx/yyy and for
# the .debug file as /usr/lib/debug/.build-id/xx/yyy.debug.
# This is the old style build_id links as generated by the original
# find-debuginfo.sh script.
#
# - separate
# build_id links are generate for all binary packages. If this is a
# main package (the __debug_package global isn't set) then the
# build_id link is generated as /usr/lib/.build-id/xx/yyy. If this is
# a -debuginfo package (the __debug_package global is set) then the
# build_id link is generated as /usr/lib/debug/.build-id/xx/yyy.
#
# - compat
# Same as for "separate" but if the __debug_package global is set then
# the -debuginfo package will have a compatibility link for the main
# ELF /usr/lib/debug/.build-id/xx/yyy -> /usr/lib/.build-id/xx/yyy
%_build_id_links compat
```
For more background see also:
https://fedoraproject.org/wiki/Changes/ParallelInstallableDebuginfo
Specifically this breaks CPackComponentsForAll-RPM-IgnoreGroup and RunCMake.CPack_RPM. See http://kojipkgs.fedoraproject.org/work/tasks/5505/18305505/build.log for full build log.3.8.0Domen 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/16620find_package(PythonInterp) + find_package(PythonLibs) problem with CMake >= 3...2017-05-04T16:23:49-04:00Cyrus Harrisonfind_package(PythonInterp) + find_package(PythonLibs) problem with CMake >= 3.4 on linuxHit this issue while evaluation moving from CMake 3.3 to CMake 3.7.
We want to seed which python libs we want to look for by calling find_package(PythonInterp), which sets the PYTHON_LIBRARY path, before calling find_package(PythonLib...Hit this issue while evaluation moving from CMake 3.3 to CMake 3.7.
We want to seed which python libs we want to look for by calling find_package(PythonInterp), which sets the PYTHON_LIBRARY path, before calling find_package(PythonLibs)
This is consistent with the docs here:
https://cmake.org/cmake/help/v3.7/module/FindPythonLibs.html
Starting with CMake 3.4, this started failing for us on a few linux platforms.
Here is the problem:
get_filename_component inside of FindPythonLibs.cmake fails b/c PYTHON_LIBRARY contains two entires:
The python lib (libpython2.7.so) and a symlink to it (libpython2.7.so.1.0)
get_filename_component expects a single entry. This error propagates and halts the configure.
Things works for us with CMake 3.3.
Below is a patch that avoids the issue, but not sure if it’s the ideal solution.
If PYTHON_LIBRARY is really supposed to be a single path, there could be other CMake logic undermined by the fact PythonInterp produces a list in some cases.
```patch
diff -c cmake-3.7.2/Modules/FindPythonLibs.cmake cmake-3.7.2-patch/Modules/FindPythonLibs.cmake
*** cmake-3.7.2/Modules/FindPythonLibs.cmake 2017-01-13 06:05:41.000000000 -0800
--- cmake-3.7.2-patch/Modules/FindPythonLibs.cmake 2017-01-31 14:28:21.000000000 -0800
***************
*** 168,174 ****
# Use the library's install prefix as a hint
set(_Python_INCLUDE_PATH_HINT)
! get_filename_component(_Python_PREFIX ${PYTHON_LIBRARY} PATH)
get_filename_component(_Python_PREFIX ${_Python_PREFIX} PATH)
if(_Python_PREFIX)
set(_Python_INCLUDE_PATH_HINT ${_Python_PREFIX}/include)
--- 168,181 ----
# Use the library's install prefix as a hint
set(_Python_INCLUDE_PATH_HINT)
! # get_filename_component(_Python_PREFIX ${PYTHON_LIBRARY} PATH)
! # the above fails when find_package(PythonInterp) returns a list with
! # both the python lib and a symlink to it.
! #
! # prevent this case by only using the first item in ${PYTHON_LIBRARY}
! # as input to get_filename_component
! list(GET ${PYTHON_LIBRARY} 0 FIRST_FOUND_PYTHON_LIBRARY)
! get_filename_component(_Python_PREFIX ${FIRST_FOUND_PYTHON_LIBRARY} PATH)
get_filename_component(_Python_PREFIX ${_Python_PREFIX} PATH)
if(_Python_PREFIX)
set(_Python_INCLUDE_PATH_HINT ${_Python_PREFIX}/include)
```
(Note: I posted this to the cmake list as well -- but here are some more links that show exactly how we are using this logic:)
https://github.com/LLNL/conduit/blob/master/src/CMake/thirdparty/SetupPython.cmake
And though its a bit verbose, you should be able to see an example of the error here:
https://circleci.com/gh/cyrush/staged-recipes/7
-Cyrus3.8.0https://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/165473.5.1 on Ubuntu 16.04.1 i686 refuses to link -ldl when using static OpenSSL2017-05-04T16:23:51-04:00Ghost User3.5.1 on Ubuntu 16.04.1 i686 refuses to link -ldl when using static OpenSSLSteps to reproduce:
```
$ git clone --recursive https://github.com/monero-project/kovri
$ cd kovri/ && git checkout a7f4b24 # current HEAD on master
$ make static
```
Successful example:
[Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-31-...Steps to reproduce:
```
$ git clone --recursive https://github.com/monero-project/kovri
$ cd kovri/ && git checkout a7f4b24 # current HEAD on master
$ make static
```
Successful example:
[Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-31-generic x86_64)
cmake version 3.5.1
GNU 5.4.0](/uploads/1d0510d3a7461d9676b8f2f2a643dca5/64.log.txt)
```
[100%] Linking CXX executable ../../kovri
cd /home/anonimal/kovri/build/src/app && /usr/bin/cmake -E cmake_link_script CMakeFiles/kovri-app.dir/link.txt --verbose=1
/usr/bin/c++ -std=c++1y -Wall -Wextra -Winvalid-pch -maes -pthread -g -static-libgcc -static-libstdc++ CMakeFiles/kovri-app.dir/main.cc.o CMakeFiles/kovri-app.dir/config.cc.o CMakeFiles/kovri-app.dir/daemon.cc.o CMakeFiles/kovri-app.dir/instance.cc.o CMakeFiles/kovri-app.dir/daemon_linux.cc.o -o ../../kovri -rdynamic ../../libkovri-client.a ../../libkovri-core.a -Wl,-Bstatic -lboost_chrono -lboost_log -lboost_program_options -lboost_date_time -lboost_thread -lboost_system -lboost_filesystem -lboost_regex -lboost_log_setup -lboost_atomic -Wl,-Bdynamic -lpthread -pthread ../../../deps/cpp-netlib/build/libs/network/src/libcppnetlib-client-connections.a -lpthread -Wl,-Bstatic -lssl -lcrypto -Wl,-Bdynamic -ldl ../../../deps/cpp-netlib/build/libs/network/src/libcppnetlib-server-parsers.a ../../../deps/cpp-netlib/build/libs/network/src/libcppnetlib-uri.a -Wl,-Bstatic -lboost_chrono -lboost_date_time -lboost_thread -lboost_system -lboost_atomic -Wl,-Bdynamic -lpthread ../../../deps/cryptopp/build/libcryptopp.a
```
Problem example:
[Ubuntu 16.04.1 LTS (GNU/Linux 4.4.0-31-generic i686)
cmake version 3.5.1
GNU 5.4.0](/uploads/355f6cd883b1cc382fee114660c47c0f/32.log.txt)
```
[100%] Linking CXX executable ../../kovri
cd /home/anonimal/kovri/build/src/app && /usr/bin/cmake -E cmake_link_script CMakeFiles/kovri-app.dir/link.txt --verbose=1
/usr/bin/c++ -std=c++1y -Wall -Wextra -Winvalid-pch -maes -pthread -g -static-libgcc -static-libstdc++ CMakeFiles/kovri-app.dir/main.cc.o CMakeFiles/kovri-app.dir/config.cc.o CMakeFiles/kovri-app.dir/daemon.cc.o CMakeFiles/kovri-app.di
r/instance.cc.o CMakeFiles/kovri-app.dir/daemon_linux.cc.o -o ../../kovri -rdynamic ../../libkovri-client.a ../../libkovri-core.a -Wl,-Bstatic -lboost_chrono -lboost_log -lboost_program_options -lboost_date_time -lboost_thread -lboost_sys
tem -lboost_filesystem -lboost_regex -lboost_log_setup -lboost_atomic -Wl,-Bdynamic -lpthread -pthread /home/anonimal/cpp-netlib/build/libs/network/src/libcppnetlib-client-connections.a -lboost_system -lboost_thread -lboost_chrono -lboost_
date_time -lboost_atomic -lpthread -Wl,-Bstatic -lssl -lcrypto /home/anonimal/cpp-netlib/build/libs/network/src/libcppnetlib-server-parsers.a /home/anonimal/cpp-netlib/build/libs/network/src/libcppnetlib-uri.a -Wl,-Bdynamic -lpthread ../..
/../deps/cryptopp/build/libcryptopp.a
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(fips.o): In function `verify_checksums':
(.text+0x46f): undefined reference to `dlopen'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(fips.o): In function `verify_checksums':
(.text+0x486): undefined reference to `dlsym'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(fips.o): In function `verify_checksums':
(.text+0x49b): undefined reference to `dladdr'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(fips.o): In function `verify_checksums':
(.text+0x4ab): undefined reference to `dlclose'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(fips.o): In function `verify_checksums':
(.text+0x4fa): undefined reference to `dlclose'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
(.text+0xa): undefined reference to `dlopen'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
(.text+0x20): undefined reference to `dlsym'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
(.text+0x2a): undefined reference to `dlclose'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
(.text+0x32d): undefined reference to `dlsym'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
(.text+0x3ad): undefined reference to `dlerror'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
(.text+0x42d): undefined reference to `dlsym'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
(.text+0x4ad): undefined reference to `dlerror'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
(.text+0x518): undefined reference to `dlopen'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
(.text+0x575): undefined reference to `dlclose'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
(.text+0x5ae): undefined reference to `dlerror'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr':
(.text+0x641): undefined reference to `dladdr'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr':
(.text+0x6a1): undefined reference to `dlerror'
/usr/lib/gcc/i686-linux-gnu/5/../../../i386-linux-gnu/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload':
(.text+0x70b): undefined reference to `dlclose'
collect2: error: ld returned 1 exit status
src/app/CMakeFiles/kovri-app.dir/build.make:226: recipe for target 'kovri' failed
make[3]: *** [kovri] Error 1
make[3]: Leaving directory '/home/anonimal/kovri/build'
CMakeFiles/Makefile2:113: recipe for target 'src/app/CMakeFiles/kovri-app.dir/all' failed
make[2]: *** [src/app/CMakeFiles/kovri-app.dir/all] Error 2
make[2]: Leaving directory '/home/anonimal/kovri/build'
Makefile:130: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/home/anonimal/kovri/build'
Makefile:114: recipe for target 'static' failed
make: *** [static] Error 2
```
Notes:
- This issue is not reproducible on [any other of our supported platforms](https://build.getmonero.org/waterfall) (only i686)
- The area which targets `dl` can also be seen [here](https://github.com/anonimal/cpp-netlib/commit/80b46bd62dab4114636ad4f316b5fb404c72aef0) for easy reference (the complete recipes are available in the submodule)
Perhaps the issue is incorrect implementation on my part?https://gitlab.kitware.com/cmake/cmake/-/issues/16540cmake-3.7.1 looks for libpthreads on ubuntu-14.042021-04-08T07:48:26-04:00Billcmake-3.7.1 looks for libpthreads on ubuntu-14.04I tried cmake 3.3.0, 3.3.2, and 3.7.1 to get an application to build on our ubuntu-14.04 box. In each case the build would die looking for -lpthreads instead of -lpthread. The cmake files seemed to be asking correctly and in tracking i...I tried cmake 3.3.0, 3.3.2, and 3.7.1 to get an application to build on our ubuntu-14.04 box. In each case the build would die looking for -lpthreads instead of -lpthread. The cmake files seemed to be asking correctly and in tracking it down I noticed cmake has the same problem when it builds itself:
```
root@crick:/share/apps/src/cmake-3.7.1# cat ./CMakeFiles/CMakeError.log | grep -i pthreads
Determining if the function pthread_create exists in the pthreads failed with the following output:
/usr/bin/gcc -w -DCHECK_FUNCTION_EXISTS=pthread_create CMakeFiles/cmTC_bd21b.dir/CheckFunctionExists.c.o -o cmTC_bd21b -rdynamic -lpthreads
/usr/bin/ld: cannot find -lpthreads
root@crick:/share/apps/src/cmake-3.7.1#
```
The libraries that cmake should find:
```
root@crick:/share/apps/src/cmake-3.7.1# locate libpthread
/lib/x86_64-linux-gnu/libpthread-2.19.so
/lib/x86_64-linux-gnu/libpthread.so.0
/usr/lib/x86_64-linux-gnu/libpthread.a
/usr/lib/x86_64-linux-gnu/libpthread.so
```
```
root@crick:/share/apps/src/cmake-3.7.1# uname -a; lsb_release -a
Linux crick 3.13.0-100-generic #147-Ubuntu SMP Tue Oct 18 16:48:51 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.5 LTS
```
At least on ubuntu-14.04 cmake should look for libpthread not libpthreads.https://gitlab.kitware.com/cmake/cmake/-/issues/16301CPack generated CMake DEB control file is malformed2018-02-20T16:28:55-05:00Nils GladitzCPack generated CMake DEB control file is malformedIn current master (1ba87fd1749ee3f46d9da1a5eb9798584a280676) the CPack DEB generator inserts the contents of the "Copyright.txt" file after the "Description:" field in the "control" file without following the formatting requirements for ...In current master (1ba87fd1749ee3f46d9da1a5eb9798584a280676) the CPack DEB generator inserts the contents of the "Copyright.txt" file after the "Description:" field in the "control" file without following the formatting requirements for multiline content[1].
When trying to install such a DEB package installation fails since the raw multiline content of Copyright.txt is not parseable.
The commit that broke this is likely 332b089ad213a1aa89658fffd8f68c9064c6d3db.
Before that "Description:" had a single line of content.
[1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-DescriptionDomen VrankarDomen Vrankarhttps://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/16293build rpath does not prevent picking up installed library when using PKG_CHEC...2018-02-20T16:28:55-05:00Dan Kegelbuild rpath does not prevent picking up installed library when using PKG_CHECK_MODULESOn Linux, cmake very nicely switches between build time rpath and installed rpath.
And it has PKG_CHECK_MODULES which lets you use libraries installed with .pc files.
So far so good.
But if one of the libraries you use via PKG_CHECK_MOD...On Linux, cmake very nicely switches between build time rpath and installed rpath.
And it has PKG_CHECK_MODULES which lets you use libraries installed with .pc files.
So far so good.
But if one of the libraries you use via PKG_CHECK_MODULES specifies an rpath,
and the library you're developing gets installed to the same place as one of those libraries,
you can end up with mysterious crashes.
Changing cmLocalGenerator::OutputLinkLibraries() to add the build rpath entries *before* the ones from CFLAGS resolves the problem.3.7.0Brad KingBrad Kinghttps://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/15994CMake support for the Linux x86-64 32-bit ABI (x32-abi)2018-02-20T16:28:57-05:00Kitware RobotCMake support for the Linux x86-64 32-bit ABI (x32-abi)This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15994). Further discussion may take place here.
---
Currently CMake assumes library files can be located in `${CMAKE_INSTALL_PRE...This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15994). Further discussion may take place here.
---
Currently CMake assumes library files can be located in `${CMAKE_INSTALL_PREFIX}/lib{64}`, or otherwise on the system in `/lib{64}`, `/usr/lib{64}` etc. This isn't the case with `x32-abi`, where library directories are postfixed with x32, for example: `${CMAKE_INSTALL_PREFIX}/libx32`
This results in CMake modules being unable to locate their resources, including failure during the configuration of CMake itself after initial bootstrap if `CMAKE_INSTALL_PREFIX` and individual `*_DIR=/usr/libx32/cmake/*` variables aren't manually provided.https://gitlab.kitware.com/cmake/cmake/-/issues/15839Create src.rpm package2018-12-07T09:57:22-05:00Kitware RobotCreate src.rpm packageThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15839). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15839). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/15668CPack: RPM: Create debuginfo package2018-12-07T09:57:29-05:00Kitware RobotCPack: RPM: Create debuginfo packageThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15668). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15668). Further discussion may take place here.https://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/15486CPackRPM - Move Component handling into .spec file2018-12-07T09:57:37-05:00Kitware RobotCPackRPM - Move Component handling into .spec fileThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15486). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15486). Further discussion may take place here.3.8.0