SUMMARY I would like to build a selection of components for an application. STEPS TO REPRODUCE elfring@Sonne:~/Projekte/KDE/src/kdesrc-build> ./kdesrc-build karchive OBSERVED RESULT The software build try fails. A file “cmake.log” contains the following information despite of the installed software package “zlib-devel 1.2.11-18.1”. “… -- The following REQUIRED packages have not been found: * ZLIB, Support for gzip compressed files and data streams, … …” EXPECTED RESULT The dependency resolution will succeed so that the build attempt can be continued.
(In reply to comment #0) Is really a manual configuration needed for corresponding CMake variables?
the log file is missing in your report. Note that FindZLIB.cmake is provided by CMake directly.
(In reply to Christophe Giboudeaux from comment #2) I observed that the script “/usr/share/cmake/Modules/FindZLIB.cmake” triggers special configuration challenges for my development system. Would you like to help any more with possible software adjustments?
FindZLIB.cmake is a relatively simple CMake module that looks for zlib headers and library. The log in your report is incomplete. CMake likely gave more details.
(In reply to Christophe Giboudeaux from comment #4) Would you find an information like the following more helpful? ~/Projekte/KDE/src/log/2020-12-13-01/karchive/cmake.log: “… -- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11") …” How do you think about to clarify any more system configuration options?
This is the feature summary, not the CMake log. mkdir build cd build cmake .. and you will see why detection fails.
(In reply to Christophe Giboudeaux from comment #6) I determined possible reasons already for the failed build checks. * I find that a storage location like “/usr/lib64/pkgconfig/zlib.pc” (or “/usr/lib64/libz.so”) should be also considered by the build script (besides the found header file). * My Linux software distribution does not provide a debug package so far. https://build.opensuse.org/package/show/openSUSE%3AFactory/zlib * I can choose a setting for the variable “ZLIB_LIBRARY” which let a build generation succeed by the program “CMake GUI 3.19.1-438.d_t_b.2”. But it seems that such a selection is not picked up by the tool “kdesrc-build” so far.
Please attach the CMake log output.
Created attachment 134079 [details] Log file variant for a build approach from 2020-12-13
(In reply to Christophe Giboudeaux from comment #8) Do you find the attachment 134079 [details] more helpful for a corresponding software build inspection?
Created attachment 134080 [details] Another log file from 2020-12-13 I hope that such data reduce the probability for undesirable misunderstandings another bit.
> -- Could NOT find ZLIB (missing: ZLIB_LIBRARY) (found version "1.2.11") This indicates the zlib headers were found but not the library. Which distribution is it? is /usr/lib64/libz.so present?
(In reply to Christophe Giboudeaux from comment #12) The package “zlib-devel 1.2.11-18.1” of the software distribution “openSUSE Tumbleweed” provides also the files “/usr/lib64/pkgconfig/zlib.pc” and “/usr/lib64/libz.so”. https://build.opensuse.org/package/view_file/openSUSE:Factory/zlib/zlib.spec
(In reply to Markus Elfring from comment #13) > (In reply to Christophe Giboudeaux from comment #12) > The package “zlib-devel 1.2.11-18.1” of the software distribution “openSUSE > Tumbleweed” provides also the files “/usr/lib64/pkgconfig/zlib.pc” and > “/usr/lib64/libz.so”. Builds fine locally and our package tracking git also builds successfully: https://build.opensuse.org/package/show/KDE:Unstable:Frameworks/karchive
(In reply to Christophe Giboudeaux from comment #14) Do you use subdirectories and file names for this library in your software build environment which are different from my system configuration?
(In reply to Christophe Giboudeaux from comment #4) Would you like to add any information to another bug report? Adjust module “FindZLIB.cmake” https://gitlab.kitware.com/cmake/cmake/-/issues/21600
(In reply to Christophe Giboudeaux from comment #12) > is /usr/lib64/libz.so present? Would you like to share further ideas for the following information? Sonne:~ # zypper in -f zlib-devel Loading repository data... Reading installed packages... Forcing installation of 'zlib-devel-1.2.11-18.1.x86_64' from repository 'Steppenläufer'. Resolving package dependencies... The following package is going to be reinstalled: zlib-devel 1 package to reinstall. Overall download size: 122.7 KiB. Already cached: 0 B. No additional space will be used or freed after the operation. Continue? [y/n/v/...? shows all options] (y): Retrieving package zlib-devel-1.2.11-18.1.x86_64 (1/1), 122.7 KiB (386.0 KiB unpacked) Retrieving: zlib-devel-1.2.11-18.1.x86_64.rpm ........................................................................................................................[done] Checking for file conflicts: .........................................................................................................................................[done] (1/1) Installing: zlib-devel-1.2.11-18.1.x86_64 ......................................................................................................................[done] Sonne:~ # ls -l /usr/lib64/libz.so /usr/lib64/libz.so.1.2.11 ls: cannot access '/usr/lib64/libz.so.1.2.11': No such file or directory lrwxrwxrwx 1 root root 14 Dec 3 18:48 /usr/lib64/libz.so -> libz.so.1.2.11
elfring@Sonne:~> locate libz.so.1.2.11 /lib/libz.so.1.2.11 /lib64/libz.so.1.2.11
(In reply to comment #0) Do I really need to “fix” a software package like “zlib-devel” (which was broken anyhow?) by a command like the following? Sonne:~ # my_target=/usr/lib64/libz.so && rm $my_target && my_zlib=libz.so.1.2.11 && cp -p "/lib64/$my_zlib" /usr/lib64 && ln -s "/usr/lib64/$my_zlib" $my_target
(In reply to comment #7) A debug package is also available with a name alternative. http://download.opensuse.org/tumbleweed/repo/debug/x86_64/libz1-debuginfo-1.2.11-18.1.x86_64.rpm
Looks like your libz1 package is obsolete. Please run zypper dup. or force a reinstallation (zypper in -f libz1). Not a KDE issue however.
(In reply to Christophe Giboudeaux from comment #21) A build attempt was temporarily affected for this software because of a known dependency on a (de)compression library.