Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 644538 - dev-util/cmake: stores incorrect paths to lib64 libraries (?)
Summary: dev-util/cmake: stores incorrect paths to lib64 libraries (?)
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Profiles (show other bugs)
Hardware: All Linux
: Normal normal with 2 votes (vote)
Assignee: Gentoo KDE team
URL: https://gitlab.kitware.com/cmake/cmak...
Whiteboard:
Keywords:
: 688252 (view as bug list)
Depends on:
Blocks: no-symlink-lib
  Show dependency tree
 
Reported: 2018-01-14 13:41 UTC by Alexander Wetzel
Modified: 2019-08-01 17:16 UTC (History)
16 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Wetzel 2018-01-14 13:41:02 UTC
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
Comment 1 Alexander Wetzel 2018-01-14 13:42:56 UTC
make the bug block 506276
Comment 2 Brian Evans Gentoo Infrastructure gentoo-dev 2018-01-14 13:54:43 UTC
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
Comment 3 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-01-14 13:55:13 UTC
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.
Comment 4 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-01-14 13:55:42 UTC
Reassigning to CMake maintainers to investigate.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-01-14 13:56:23 UTC
(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.
Comment 6 Brian Evans Gentoo Infrastructure gentoo-dev 2018-01-14 14:02:45 UTC
(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
Comment 7 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2018-06-17 06:43:39 UTC
So did anyone figure out whether it's coming from cmake or the relevant packages are doing some custom thing?
Comment 8 Andreas Sturmlechner gentoo-dev 2018-06-17 14:27:56 UTC
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.
Comment 9 Bernd 2019-06-10 22:48:34 UTC
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
Comment 10 Bernd 2019-06-12 21:02:03 UTC
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.
Comment 11 Andreas Sturmlechner gentoo-dev 2019-06-12 21:03:26 UTC
python certainly does not use cmake.
Comment 12 Reinis Danne 2019-06-17 09:32:55 UTC
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)
Comment 13 Reinis Danne 2019-06-17 11:47:16 UTC
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
Comment 14 Brian Evans Gentoo Infrastructure gentoo-dev 2019-06-17 23:12:07 UTC
*** Bug 688252 has been marked as a duplicate of this bug. ***
Comment 15 Alexander 2019-06-22 09:41:17 UTC
(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…
Comment 16 Larry the Git Cow gentoo-dev 2019-06-22 11:44:30 UTC
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(+)
Comment 17 Andreas Sturmlechner gentoo-dev 2019-06-23 20:39:01 UTC
(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.