It looks like the instructions in the news to migrate from 17.0 to 17.1 may be incomplete. Here what happened on my system: - Migration was completed, everything ok - Some weeks later A world update tried to update "kde-apps/ktp-call-ui" from 17.08.3 to 17.12.1 and failed. Error message was (from memory): "No rule to make "/usr/lib/libtelepathy-farstream.so" The library is installed, but in /usr/lib64 and not in /usr/lib. The wrong path got injected into the buld process from "/usr/lib64/cmake/TelepathyQt5/TelepathyQt5Targets.cmake" The correct fix for me was to run "emerge -1av net-libs/telepathy-qt", which corrected the patch in the cmake file above. Here how the critical section in the cmake file looked prior to the update to profile 17.1 (still have the backup): set_target_properties(telepathy-qt5-farstream PROPERTIES INTERFACE_LINK_LIBRARIES "Qt5::DBus;Qt5::Core;gobject-2.0;glib-2.0;/usr/lib64/libglib-2.0.so;/usr/lib/libtelepathy-farstream.so;/usr/lib/libtelepathy-glib.so;telepathy-qt5" ) This line was (again from memory) unchanged after the migration was completed. For me it looks like the instructions are only rebuilding the libraries, but not the packages depending on them and creating the /usr/lib64/cmake/* files. A quick grep over the /usr/lib64/cmake files brought up more misfits on my system: The cmake files belonging to the packages from the first column have libraries belonging to the second column referenced at /usr/lib instead of /usr/lib64: Owner of cmake file Owner of wrongly referenced library net-libs/telepathy-qt net-libs/telepathy-farstream dev-libs/libical dev-libs/icu kde-frameworks/baloo dev-db/lmdb kde-frameworks/kdelibs media-libs/phonon Rebuilding those packages fixes the path in the cmake files. Not sure if there is a better way, but looks like we need to do something like "emerge -1v /usr/lib64/cmake" during the migration, too. I ended up rebuilding all packages which had files with the string "/usr/lib/" in a cmake file located under /usr/lib64/cmake
make the bug block 506276
Looks like files in /usr/lib64/pkgconfig/ should also be considered: grep -r /lib/ /usr/lib64/pkgconfig/ /usr/lib64/pkgconfig/ck-connector.pc:libexecdir=/usr/lib/ConsoleKit /usr/lib64/pkgconfig/krb5.pc:defcktname=FILE:/var/lib/krb5/user/%{euid}/client.keytab /usr/lib64/pkgconfig/libconsolekit.pc:libexecdir=/usr/lib/ConsoleKit /usr/lib64/pkgconfig/mit-krb5.pc:defcktname=FILE:/var/lib/krb5/user/%{euid}/client.keytab
This looks like either bug in CMake itself, or in the packages using CMake. Using /usr/lib paths for 64-bit libraries is simply invalid, and shouldn't ever happen, SYMLINK_LIB or not.
Reassigning to CMake maintainers to investigate.
(In reply to Brian Evans from comment #2) > Looks like files in /usr/lib64/pkgconfig/ should also be considered: > > grep -r /lib/ /usr/lib64/pkgconfig/ > /usr/lib64/pkgconfig/ck-connector.pc:libexecdir=/usr/lib/ConsoleKit > /usr/lib64/pkgconfig/krb5.pc:defcktname=FILE:/var/lib/krb5/user/%{euid}/ > client.keytab > /usr/lib64/pkgconfig/libconsolekit.pc:libexecdir=/usr/lib/ConsoleKit > /usr/lib64/pkgconfig/mit-krb5.pc:defcktname=FILE:/var/lib/krb5/user/%{euid}/ > client.keytab Please file a separate bug for consolekit. The other is a misgrep.
(In reply to Michał Górny from comment #5) > (In reply to Brian Evans from comment #2) > > Looks like files in /usr/lib64/pkgconfig/ should also be considered: > > > > grep -r /lib/ /usr/lib64/pkgconfig/ > > /usr/lib64/pkgconfig/ck-connector.pc:libexecdir=/usr/lib/ConsoleKit > > /usr/lib64/pkgconfig/krb5.pc:defcktname=FILE:/var/lib/krb5/user/%{euid}/ > > client.keytab > > /usr/lib64/pkgconfig/libconsolekit.pc:libexecdir=/usr/lib/ConsoleKit > > /usr/lib64/pkgconfig/mit-krb5.pc:defcktname=FILE:/var/lib/krb5/user/%{euid}/ > > client.keytab > > Please file a separate bug for consolekit. The other is a misgrep. These appear to be false positives
So did anyone figure out whether it's coming from cmake or the relevant packages are doing some custom thing?
Both cmake and individual packages are problematic. At least the following modules installed by CMake find libs in /usr/lib rather than the suffixed paths: FindALSA.cmake (a fix should let it use pkg_check_modules) FindBoost.cmake (fixed by -DBOOST_LIBRARYDIR arg) FindOpenGL.cmake (not sure how to fix) FindZLIB.cmake (fixed by -DZLIB_ROOT arg) And then cmake modules calling find_library are affected too unless they specifically add e.g. LIB_SUFFIX hints. At least kde-frameworks/baloo and net-libs/telepathy-qt are easily fixed for that. FindCGAL.cmake as installed by sci-mathematics/cgal-4.11.1 does not care about how it was configured with -DCGAL_INSTALL_LIB_DIR either. In addition, this package does get various find_library hints wrong. Add to the list of broken cmake files: app-office/libalkimia media-libs/oyranos sci-chemistry/ball (probably caused by FindBoost.cmake) sci-chemistry/molequeue sci-chemistry/openbabel sci-libs/avogadrolibs (probably caused by FindOpenGL.cmake) sci-libs/vtk-7.1 --- dev-libs/libical-3.0.3 seems to be fine (unmasking blocked by xfce). kde-frameworks/kdelibs will be fixed by removal shortly.
Most references got away after I re-emerged the package in question. However, those packages remain: dev-lang/mono::dotnet, just updated today, also installs into /usr/lib, although I don't have abi_x86_32 enabled for the package and puts pkg-config files with reference to /usr/lib into /usr/lib64/pkgconfig media-video/ffmpegthumbnailer installs a pkg-config file which references libdir as ${exec_prefix}/lib media-video/obs-studio install a pkgconfig file into /usr/lib/pkgconfig with libdir set to ${prefix}/lib64 The same holds true for sci-libs/blas-reference, sci-libs/cblas-reference and sci-libs/lapack-reference from the science overlay. All three additionally install a ${pkg}-int64.pc file into /usr/lib/pkgconfig which should IMO not installed for 32bit arches. I'm going to open an issue on the science github page for those. net-libs/libssh: libssh-config.cmake reference to "${CMAKE_CURRENT_LIST_DIR}/lib/libssh.so" net-libs/libssh2: installs cmake files only into /usr/lib/cmake containing references to lib64
Today, I noticed, that python-3.7 might also need some fixing after migrating to 17.1 profile. While working to add python-3.7 support for dev-python/pycollada, src_install puts the python-3.7 files into ${ED}/usr/lib/python-3.7/site-packages, while the python-3.6 files correctly go into ${ED}/usr/lib64/python-3.6/site-packages. python3.7-config --configdir outputs /usr/lib/python3.7/config-3.7m-x86_64-linux-gnu. Simply re-emerging python:3.7 didn't solve this. It still installs files into /usr/lib instead of /usr/$(get_libdir). I have python-3.7.3 installed.
python certainly does not use cmake.
I got a bunch of build failures after migrating to 17.1 profile (multilib ~amd64), because it tries to link against 32bit zlib during 64bit build. Even cmake itself fails to build due to this. /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/lib/libz.so: error adding symbols: file in wrong format # file /usr/lib/lib/libz.so.1.2.11 > /usr/lib/lib/libz.so.1.2.11: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped # file /lib64/libz.so.1.2.11 > /lib64/libz.so.1.2.11: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped The problem is in file /usr/share/cmake/Modules/FindZLIB.cmake. Replacing "lib" with "lib64" PATH_SUFFIXES works around it, but I'm not sure if this is the correct fix. > - find_library(ZLIB_LIBRARY_RELEASE NAMES ${ZLIB_NAMES} NAMES_PER_DIR ${${search}} PATH_SUFFIXES lib) > - find_library(ZLIB_LIBRARY_DEBUG NAMES ${ZLIB_NAMES_DEBUG} NAMES_PER_DIR ${${search}} PATH_SUFFIXES lib) > + find_library(ZLIB_LIBRARY_RELEASE NAMES ${ZLIB_NAMES} NAMES_PER_DIR ${${search}} PATH_SUFFIXES lib64) > + find_library(ZLIB_LIBRARY_DEBUG NAMES ${ZLIB_NAMES_DEBUG} NAMES_PER_DIR ${${search}} PATH_SUFFIXES lib64)
The same issue with freetype (/usr/share/cmake/Modules/FindFreetype.cmake) when building kwin and webkit-gtk: /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ld.gold: error: /usr/lib/lib/libfreetype.so: incompatible target # file /usr/lib/lib/libfreetype.so.6.17.0 > /usr/lib/lib/libfreetype.so.6.17.0: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped # file /usr/lib64/libfreetype.so.6.17.0 > /usr/lib64/libfreetype.so.6.17.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped
*** Bug 688252 has been marked as a duplicate of this bug. ***
(In reply to Reinis Danne from comment #12) > I got a bunch of build failures after migrating to 17.1 profile (multilib > ~amd64), because it tries to link against 32bit zlib during 64bit build. > Even cmake itself fails to build due to this. > > /usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/../../../../x86_64-pc-linux-gnu/bin/ > ld: /usr/lib/lib/libz.so: error adding symbols: file in wrong format Confirm @Reinis Danne words. Today, I rebuilt `dev-libs/libffi` with dependences, and `sys-devel/llvm` package has failed to build abi_x86_32 again. /tmp/portage/sys-devel/llvm-6.0.1-r2/temp/build-abi_x86_32.x86.log ```bash … [1203/1571] : FAILED: lib32/libLLVMInterpreter.so.6.0.1 /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libffi.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status … ``` ```bash % grep -rn 'r/lib/libffi.so' /tmp/portage/sys-devel/llvm-6.0.1-r2/work/llvm-6.0.1.src-abi_x86_32.x86 build.ninja:15257:build lib32/libLLV … t.so.6.0.1 /usr/lib/libffi.so lib32/libLL … ort.so.6.0.1 /usr/lib/libffi.so lib32/libLLV … src-abi_x86_32.x86/lib32 CMakeCache.txt:322:FFI_LIBRARY_PATH:FILEPATH=/usr/lib/libffi.so CMakeCache.txt:421:LLVMInterpreter_LIB_DEPENDS:STATIC=general;LLVMCodeGen;general;LLVMCore;general;LLVMExecutionEngine;general;LLVMSupport;general;/usr/lib/libffi.so; CMakeFiles/CMakeError.log:304:: && /usr/bin/x86_64-pc-linux-gnu-gcc -m32 -march=ivybridge -mtune=ivybridge -mavx -mcx16 -mf16c -mfsgsbase -mfxsr -mmmx -mno-3dnow -mno-abm -mno-adx -mno-aes -mno-avx2 -mno-avx512bw -mno-avx512cd -mno-avx512dq -mno-avx512er -mno-avx512f -mno-avx512ifma -mno-avx512pf -mno-avx512vbmi -mno-avx512vl -mno-bmi -mno-bmi2 -mno-clflushopt -mno-clwb -mno-clzero -mno-fma -mno-fma4 -mno-hle -mno-lwp -mno-lzcnt -mno-movbe -mno-mwaitx -mno-pku -mno-prefetchwt1 -mno-prfchw -mno-rdrnd -mno-rdseed -mno-rtm -mno-sha -mno-sse4a -mno-tbm -mno-xop -mno-xsavec -mno-xsaves -mpclmul -mpopcnt -msahf -msse -msse2 -msse3 -msse4.1 -msse4.2 -mssse3 -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 -O2 -pipe -Wl,-O1 -Wl,--as-needed CMakeFiles/cmTC_ea2f1.dir/CheckSymbolExists.c.o -o cmTC_ea2f1 -lm /usr/lib/libffi.so && : CMakeFiles/CMakeError.log:305:/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libffi.so: error adding symbols: file in wrong format ``` Quick „by hand solution“: ```bash % cd /tmp/portage/sys-devel/llvm-6.0.1-r2/work/llvm-6.0.1.src-abi_x86_32.x86 % sed -i -e 's|r/lib/libffi|r/lib32/libffi|g' build.ninja CMakeCache.txt % cd ~ % ebuild portage/sys-devel/llvm/llvm-6.0.1-r2.ebuild install merge ``` I think maybe `multilib-minimal.eclass` and\or `cmake-utils.eclass` was damaged. `media-libs/vulkan-layers` ```bash % grep " error" /tmp/portage/media-libs/vulkan-layers-1.1.92.0-r1/temp/build-abi_x86_32.x86.log /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libSPIRV-Tools-opt.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status make[2]: Target 'layers/CMakeFiles/VkLayer_core_validation.dir/build' not remade because of errors. make[1]: Target 'all' not remade because of errors. make: Target 'default_target' not remade because of errors. ``` `dev-util/vulkan-tools` ```bash % grep " error" /tmp/portage/dev-util/vulkan-tools-1.1.92.0/temp/build-abi_x86_32.x86.log /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libxcb.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status make[2]: Target 'vulkaninfo/CMakeFiles/vulkaninfo.dir/build' not remade because of errors. /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libxcb.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status make[2]: Target 'cube/CMakeFiles/vkcube.dir/build' not remade because of errors. /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libxcb.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status make[2]: Target 'cube/CMakeFiles/vkcubepp.dir/build' not remade because of errors. /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libvulkan.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libSM.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status make[2]: Target 'cube/CMakeFiles/vkcube.dir/build' not remade because of errors. make[2]: Target 'vulkaninfo/CMakeFiles/vulkaninfo.dir/build' not remade because of errors. /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libvulkan.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status make[2]: Target 'cube/CMakeFiles/vkcubepp.dir/build' not remade because of errors. /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libICE.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status make[2]: Target 'vulkaninfo/CMakeFiles/vulkaninfo.dir/build' not remade because of errors. /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libX11.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status make[2]: Target 'vulkaninfo/CMakeFiles/vulkaninfo.dir/build' not remade because of errors. /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libXext.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status make[2]: Target 'vulkaninfo/CMakeFiles/vulkaninfo.dir/build' not remade because of errors. /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib/libwayland-client.so: error adding symbols: file in wrong format collect2: error: ld returned 1 exit status make[2]: Target 'vulkaninfo/CMakeFiles/vulkaninfo.dir/build' not remade because of errors. make[1]: Target 'all' not remade because of errors. make: Target 'default_target' not remade because of errors. ``` And so others…
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0dbaa3a980de231efcae354207433fd14d148ebb commit 0dbaa3a980de231efcae354207433fd14d148ebb Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2019-06-12 12:14:34 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-06-22 11:44:01 +0000 media-video/obs-studio: version bump to 23.2.1 Comes with a patch to correct the 'libdir' for 'libobs.pc'. Upstream PR: https://github.com/obsproject/obs-studio/pull/1932 Bug: https://bugs.gentoo.org/644538 Package-Manager: Portage-2.3.67, Repoman-2.3.14 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/12246 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> media-video/obs-studio/Manifest | 1 + .../obs-studio-23.2.1-use-correct-libdir.patch | 50 ++++++++ media-video/obs-studio/obs-studio-23.2.1.ebuild | 132 +++++++++++++++++++++ 3 files changed, 183 insertions(+)
(In reply to Bernd from comment #9) > net-libs/libssh: libssh-config.cmake reference to > "${CMAKE_CURRENT_LIST_DIR}/lib/libssh.so" No works fine for Gentoo, this is hidden behind checking for ${CMAKE_CURRENT_LIST_DIR}/CMakeCache.txt existence. In fact I just fixed (that part of) exiv2 by switching to libssh-config usage.
*** Bug 686750 has been marked as a duplicate of this bug. ***
*** Bug 683796 has been marked as a duplicate of this bug. ***
*** Bug 688012 has been marked as a duplicate of this bug. ***
*** Bug 690056 has been marked as a duplicate of this bug. ***
Maybe this bug is related? https://bugs.gentoo.org/753581
