Created attachment 646410 [details] emerge --info /usr/lib/gcc/x86_64-pc-linux-gnu/9.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libcheck.so: error adding symbols: file in wrong format
Created attachment 646412 [details] build.log
I don't think this has anything to do with no-symlink-lib or even libevdev. The problem is that check's pc file is wrong: # cat /usr/lib/pkgconfig/check.pc prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: Check Description: A unit test framework for C URL: https://libcheck.github.io/check/ Version: 0.15.2 Requires.private: Libs: -L/usr/lib64 -lcheck Libs.private: -pthread -lm -lrt Cflags: -I${includedir} -pthread Notice the -L/usr/lib64.
After src_unpack: # grep Libs: /var/tmp/portage/dev-libs/check-0.15.2/work/check-0.15.2/check.pc.in After src_prepare: grep Libs: /var/tmp/portage/dev-libs/check-0.15.2/work/check-0.15.2/check.pc.in Libs: -L/usr/lib64 -lcheck
Oh yeah. # Fix wrong libdir, probably caused by multilib sed -i "s|\${libdir}|/usr/$(get_libdir)|g" check.pc.in || die "sed .pc failed." How did we ever expect this to work?
(In reply to Matt Turner from comment #2) > I don't think this has anything to do with no-symlink-lib or even libevdev. > Yeah, I added it because such bugs cause problems for people still migrating - like most of the bugs for it. (In reply to Matt Turner from comment #3) > After src_unpack: > > # grep Libs: > /var/tmp/portage/dev-libs/check-0.15.2/work/check-0.15.2/check.pc.in > > After src_prepare: > > grep Libs: > /var/tmp/portage/dev-libs/check-0.15.2/work/check-0.15.2/check.pc.in > Libs: -L/usr/lib64 -lcheck In src_prepare: # Fix wrong libdir, probably caused by multilib sed -i "s|\${libdir}|/usr/$(get_libdir)|g" check.pc.in || die "sed .pc failed." But this is wrong if we're in the multilib case.
Looks like the fix for bug 714058 was put into the wrong src_* function.
As I don't use/do multilib or cross-compile I'd be guessing what the correct phase is. multilib_src_configure() { if multilib_is_native_abi; then sed ? Or some hackery in multilib_src_install() { if multilib_is_native_abi; then find -exec sed ?
(In reply to Joonas Niilola from comment #7) > As I don't use/do multilib or cross-compile I'd be guessing what the correct > phase is. > > multilib_src_configure() { > if multilib_is_native_abi; then > sed > > ? > > Or some hackery in > multilib_src_install() { > if multilib_is_native_abi; then > find -exec sed > ? I would do the latter in m_s_i and unconditionally sed to the appropriate libdir (so we aren’t assuming anything about which is native etc, I believe riscv was nearly weird here).
--- /var/db/repos/gentoo/dev-libs/check/check-0.15.2.ebuild 2021-01-07 15:59:59.780714739 -0000 +++ ./check-0.15.2-r1.ebuild 2021-03-10 10:21:30.327967818 -0000 @@ -27,13 +27,6 @@ PATCHES=( "${FILESDIR}/check-0.14.0-r2-disable-automagic-dep.patch" ) -src_prepare() { - cmake_src_prepare - - # Fix wrong libdir, probably caused by multilib - sed -i "s|\${libdir}|/usr/$(get_libdir)|g" check.pc.in || die "sed .pc failed." -} - multilib_src_configure() { local mycmakeargs=( -DBUILD_TESTING=$(usex test ON OFF) @@ -52,6 +45,11 @@ fi } +multilib_src_install() { + cmake_src_install + find "${ED}" -name 'check.pc' -exec sed -i "s|\${libdir}|/usr/$(get_libdir)|g" {} \; || die +} + multilib_src_install_all() { use doc && local HTML_DOCS=( "${S}"/doc/html/. ) einstalldocs But I honestly can't perceive any difference to how it's currently working. Same files get created with same content.
The root of the problem is that libdir is wrong. % grep libdir /usr/lib64/pkgconfig/check.pc libdir=${exec_prefix}/lib The sed hack just worked around that, but broke non-default ABIs in the process.
And that's because it's hardcoded in CMakeLists.txt: set(libdir "\${exec_prefix}/lib")
Upstream pull request opened.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=85035e3ff63b4153763fc5f4b234a04f979e025a commit 85035e3ff63b4153763fc5f4b234a04f979e025a Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2021-03-21 00:49:50 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2021-03-21 00:51:57 +0000 dev-libs/check: Fix pkgconfig file's libdir Closes: https://bugs.gentoo.org/729642 Signed-off-by: Matt Turner <mattst88@gentoo.org> ...{check-0.15.2.ebuild => check-0.15.2-r1.ebuild} | 16 ++++++------ ...-0.15.2-Fix-pkgconfig-file-s-libdir-value.patch | 30 ++++++++++++++++++++++ 2 files changed, 38 insertions(+), 8 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=0ac65ddf7cff60a64730ca7c123f492fb68217a4 commit 0ac65ddf7cff60a64730ca7c123f492fb68217a4 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-28 00:38:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-04-12 01:59:53 +0000 install-qa-check.d/60pkgconfig: check for not respecting libdir in pc files It's not valid to reference lib64 when installing to /usr/lib where we want 32-bit libraries. We want to make sure that if we're installing a pkgconfig file for a 32-bit variant (multilib), we make sure that the file references the right library: it should have e.g. /usr/lib, not /usr/lib64, or consumers trying to use the 32-bit library will try to link against a 64-bit library. (We also cover the opposite case: /usr/lib64 pkgconfig files referencing /usr/lib). Bug: https://bugs.gentoo.org/729642 Signed-off-by: Sam James <sam@gentoo.org> bin/install-qa-check.d/60pkgconfig | 37 ++++++++++++++++++++++++++++++++++++- 1 file changed, 36 insertions(+), 1 deletion(-)
