Created attachment 592734 [details] build.log Build fails when linking "/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libtag.so when searching for -ltag /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libz.so when searching for -lz /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libz.a when searching for -lz /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libm.so when searching for -lm /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libm.a when searching for -lm /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.so when searching for -lc /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -lc /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: i386 architecture of input file `/var/tmp/portage/kde-frameworks/kfilemetadata-5.63.0/temp/libKF5FileMetaData.so.5.63.0.khDGlZ.ltrans0.ltrans.o' is incompatible with i386:x86-64 output collect2: error: ld returned 1 exit status " (build.log and above error are with CFLAGS="-march=native -O2 -pipe" and the same CXXFLAGS) Forcing it to search in /usr/lib64 (by adding -L/usr/lib64 to C and CXXFLAGS) fixes the build.
Created attachment 592736 [details] emerge --info
can't reproduce it in a cleaner chroot (that doesn't globally set abi_x86_32 ) .. guess somethings inconsistent in my install somewhere?
Sounds like an incomplete profile 17.1 switch.
Actually.. I did find something after all. It's taglib, to be more specific, =media-libs/taglib-1.11.1_p20190920 . taglib-config --libs reports /usr/lib while my test chroot had the stable version (tested the unstable on in my chroot and it reported /usr/lib there too) . the stable taglib-config --libs reports /usr/lib64 on both my real install and chroot.
I still am doing a full emerge -e world to try to shake loose any more issues on my main install since my chroot still manages to build kfilemetadata even with the faulty ~amd64 taglib-config (reverting to the stable taglib fixed the kfilemetadata build on my main install). Any other suggestions let me know, the original migration rebuild of anything claiming */lib32 just says nothing claims those paths.
I even did a reinstall and only brought over my /etc/portage and my world file and this same build failure happened with the ~amd64 taglib. (with a recent stage 3 that was always 17.1)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f5376c03c8c65c581901c4dee29a05cf2bae2327 commit f5376c03c8c65c581901c4dee29a05cf2bae2327 Author: Andreas Sturmlechner <asturm@gentoo.org> AuthorDate: 2019-10-20 14:17:09 +0000 Commit: Andreas Sturmlechner <asturm@gentoo.org> CommitDate: 2019-10-20 14:19:38 +0000 media-libs/taglib: Fix taglib-config libdir Pending upstream PR: https://github.com/taglib/taglib/pull/935 Closes: https://bugs.gentoo.org/697742 Package-Manager: Portage-2.3.77, Repoman-2.3.17 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org> .../files/taglib-1.11.1_p20181028-libdir.patch | 25 ++++++++++++++++++++++ ...20.ebuild => taglib-1.11.1_p20190920-r1.ebuild} | 1 + 2 files changed, 26 insertions(+)
