Description
Fabio Coatti
2023-01-05 10:17:22 UTC
For completeness, can you include: 1. build.log of a package which broke (threadweaver is fine, but if you can find something "simpler", that might be useful too) 2. CMakeOutput.log as well for the same package as 1. Thanks! I picked kde-misc/openofficeorg-thumbnail-1.0.0-r500 that seems simple enough. Attached you can find bot files as requested. Thanks! Created attachment 847336 [details]
Build log
Created attachment 847338 [details]
cmake output
Could you remove the word "QUIET" from line 49 of /usr/share/ECM/modules/ECMQueryQt.cmake, and retry building kde-misc/openofficeorg-thumbnail? That might provide a more useful error.
> find_package(Qt${QT_MAJOR_VERSION}Core QUIET)
(In reply to Mike Gilbert from comment #5) > Could you remove the word "QUIET" from line 49 of > /usr/share/ECM/modules/ECMQueryQt.cmake, and retry building > kde-misc/openofficeorg-thumbnail? That might provide a more useful error. > > > find_package(Qt${QT_MAJOR_VERSION}Core QUIET) The visible difference in build is this message: CMake Warning at /usr/share/ECM/modules/ECMQueryQt.cmake:49 (find_package): By not providing "FindQt5Core.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "Qt5Core", but CMake did not find one. Could not find a package configuration file provided by "Qt5Core" with any of the following names: Qt5CoreConfig.cmake qt5core-config.cmake Add the installation prefix of "Qt5Core" to CMAKE_PREFIX_PATH or set "Qt5Core_DIR" to a directory containing one of the above files. If "Qt5Core" provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): /usr/share/ECM/kde-modules/KDEInstallDirs5.cmake:240 (include) /usr/share/ECM/kde-modules/KDEInstallDirs.cmake:15 (include) CMakeLists.txt:11 (include) No other differences either in build.log and cmake log. (only trivial temp files names) Does /usr/lib64/cmake/Qt5Core/Qt5CoreConfig.cmake exist on your system? It should be provided by dev-qt/qtcore:5. Also, you have a 23.0 profile selected. You should know that 23.0 is NOT ready for general use. (In reply to Mike Gilbert from comment #8) > Does /usr/lib64/cmake/Qt5Core/Qt5CoreConfig.cmake exist on your system? > > It should be provided by dev-qt/qtcore:5. ⌙➤ ls -la /usr/lib64/cmake/Qt5Core/Qt5CoreConfig.cmake -rw-r--r-- 1 root root 11207 Dec 20 10:31 /usr/lib64/cmake/Qt5Core/Qt5CoreConfig.cmake Now I'm re emerging qtcore just in case, but the file is there. > Also, you have a 23.0 profile selected. > You should know that 23.0 is NOT ready for general use. yep, I'm not complaining about this issue, I'm just trying to figure out what is going on, if this could help others to run in the same issue If it could be useful, in a package (sys-fs/cryfs) requiring boost i get this error: -- Found Threads: TRUE -- Boost will be dynamically linked CMake Error at /usr/lib/cmake/Boost-1.81.0/BoostConfig.cmake:141 (find_package): Found package configuration file: /usr/lib/cmake/boost_filesystem-1.81.0/boost_filesystem-config.cmake but it set boost_filesystem_FOUND to FALSE so package "boost_filesystem" is considered to be NOT FOUND. Reason given by package: No suitable build variant has been found. The following variants have been tried and rejected: * libboost_filesystem.so.1.81.0 (32 bit, need 64) Call Stack (most recent call first): /usr/lib/cmake/Boost-1.81.0/BoostConfig.cmake:262 (boost_find_component) /usr/share/cmake/Modules/FindBoost.cmake:594 (find_package) cmake-utils/utils.cmake:119 (find_package) src/cpp-utils/CMakeLists.txt:98 (target_add_boost) Apparently, it seems another effect of the same issue It seems like cmake is ignoring /usr/lib64/cmake and is looking in /usr/lib/cmake instead. I'm not sure what would cause that, but I don't think it is directly related to the usr merge. (In reply to Mike Gilbert from comment #12) > It seems like cmake is ignoring /usr/lib64/cmake and is looking in > /usr/lib/cmake instead. I'm not sure what would cause that, but I don't > think it is directly related to the usr merge. I can't argue with that, but if this is the case I wonder what change triggered this behavior and more importantly how can it be fixed. Could it be that the search is done in lexicographic order and the changes affected that? Just a stab in the dark, admittedly. In the meantime, I found a way around this issue by forcing the prefix for cmake: export CMAKE_PREFIX_PATH=/usr/lib64/cmake ; emerge [...] This allows the compilation to complete. (In reply to Fabio Coatti from comment #14) Interesting. It might be worth doing something like that in cmake.eclass. I can confirm this issue and resolved it by add GetRealPath to FullPathCollapse in cmake Created attachment 848549 [details, diff]
dev-util/cmake-3.25.1 add GetRealPath to CollapseFullPath
Created attachment 848551 [details]
[New Ebuild] dev-util/cmake-3.25.1-r1.ebuild
See Also: https://bugs.gentoo.org/889822 I just tried and the reported issue is indeed solved, as I can avoid to use export CMAKE_PREFIX_PATH=/usr/lib64/cmake ; emerge [...] However, now I end up in this situation: r/cmCursesPathWidget.cxx.o CMakeFiles/ccmake.dir/cmCursesStringWidget.cxx.o CMakeFiles/ccmake.dir/cmCursesWidget.cxx.o -o ../../bin/ccmake ../../libCMakeLib.a /usr/lib/libform.so /usr/lib/libncurses.so /usr/lib/libtinfo.so ../../libcmstd.a ../../libcmsys.a -ldl /usr/lib64/libcurl.so /usr/lib64/libexpat.so /usr/lib64/libjsoncpp.so /usr/lib/libarchive.so /usr/lib/librhash.so /usr/lib64/libuv.so /usr/lib/libz.so /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libform.so: error adding symbols: file in wrong format Basically cmake finds the wrong lib (32) instead of the right one. Looking at the checks performed to find libs, it seems that the check fails with 32bit libs but the failure is not detected and lib it is used. I'm not sure if this can be considered the same bug or another one, hence I'm not sure if it is better to open another bug or provide details here. (In reply to Jon Daniel from comment #17) > Created attachment 848549 [details, diff] [details, diff] > dev-util/cmake-3.25.1 add GetRealPath to CollapseFullPath Could you send this upstream at https://gitlab.kitware.com/cmake/cmake? It'd be really helpful if you could try replicate this in a clean chroot (extract to /tmp or some other temp. location) and figure out steps to make it happen again. (In reply to Sam James from comment #22) > It'd be really helpful if you could try replicate this in a clean chroot > (extract to /tmp or some other temp. location) and figure out steps to make > it happen again. Will try to do that. In the meanwhile, I fiddled around with cmake.eclass and I was able to have llvm/lld and other cmake based packages to compile. As you may see, it is some "hack&pray" approach, with debug lines sprinkled around and an llvm hardcoded path. In any way, this stuff allowed me to get to the bottom of compilation, barring the case of firefox ( bug #894452 )that is not using the eclass apparently: if [[ "${ARCH}" == amd64 ]]; then einfo "Current ABI ${ABI}" if [[ "${ABI}" == "amd64" ]]; then sed -i '/CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX/d' "${common_config}" sed -i '/CMAKE_PREFIX_PATH/d' "${common_config}" echo 'set(CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX '"64"' CACHE STRING "library search suffix" FORCE)' >> "${common_config}" || die echo 'set(CMAKE_PREFIX_PATH "/usr/lib64/cmake" CACHE STRING "" FORCE)' >> "${common_config}" || die export CMAKE_PREFIX_PATH=/usr/lib64/cmake export LLVM_DIR=/usr/lib/llvm/15/lib64/cmake/llvm ewarn "$(env)" einfo "ABI 64 TRIGGERED" elif [[ "${ABI}" == "x86" ]]; then sed -i '/CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX/d' "${common_config}" sed -i '/CMAKE_PREFIX_PATH/d' "${common_config}" echo 'set(CMAKE_FIND_LIBRARY_CUSTOM_LIB_SUFFIX '""' CACHE STRING "library search suffix" FORCE)' >> "${common_config}" || die echo 'set(CMAKE_PREFIX_PATH "/usr/lib/cmake" CACHE STRING "" FORCE)' >> "${common_config}" || die ewarn "$(env)" einfo "ABI 32 TRIGGERED" else eerror "ABI ${ABI} UNEXPECTED" fi fi (I know, ugly, but again it's just poking around) I finally got to the bottom (more or less of this issue). Basically it seems that I had some old/weird stuff, probably old configuration leftovers that apparently confused cmake modules, thus preventing a proper libs detection. Cmake itself was not providing enough details to spot the issue (or I was not good enough in spotting it, more likely). I got it fixed when I decided to run thru basically all /etc/ files and removing anything not understandable as recent or meaningful config. After that and after a "env-update" things started to behave properly. Sorry for the noise.. at least this could be a reminder for the future: "cmake is a beast to manage with care :) " |