Summary: | sys-libs/glibc: src_install on no-multilib profiles breaks various libdir paths | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Xavier Miller (RETIRED) <xaviermiller> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED FIXED | ||
Severity: | critical | CC: | bkohler, hoess, jaco, mjo, reznikmm, skunk, walter |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log.gz |
Description
Xavier Miller (RETIRED)
2014-09-15 18:41:09 UTC
FWIW, several users have reported this issue in #gentoo the last few days. I think you'll find that ${D}/lib64/ld-linux-x86-64.so.2 is a symlink to itself rather than to ld-2.19.so as it should be. Why, and what to do with that, I do not know. It compiled fine on 2014-08-27 Please attach the entire build log to this bug report. Created attachment 384820 [details]
build.log.gz
here it is
I experience the same issue: glibc-emerging works on my hardened/multilib-machines, but fails on two hardened/NOmultilib-machines. I also find that ${D}/lib64/ld-linux-x86-64.so.2 is a symlink to itself. One of these machines was able to emerge glibc-2.19-r1 earlier on Aug 14, 2014, but re-emerging fails now. I tried emerging earlier versions of glibc but this fails with the same error. Upgrading or downgrading sys-app/portage from current stable did not help. Same here, on all of my machines. The ChangeLog shows a bunch of changes to files/eblits/src_install.eblit on Sep 10 which I would be suspect of. Couple of notes: * There is nothing in lib64 except this broken link * ld-2.19.so located in ../lib/ * There is no lib32 directory at all # ls -l /var/tmp/portage/sys-libs/glibc-2.19-r1/image/lib64 total 0 lrwxrwxrwx 1 root root 29 Sep 16 16:47 ld-linux-x86-64.so.2 -> ../lib64/ld-linux-x86-64.so.2 # ls -l /var/tmp/portage/sys-libs/glibc-2.19-r1/image/lib/ld-* -rwxr-xr-x 1 root root 140584 Sep 16 16:48 /var/tmp/portage/sys-libs/glibc-2.19-r1/image/lib/ld-2.19.so lrwxrwxrwx 1 root root 10 Sep 16 16:47 /var/tmp/portage/sys-libs/glibc-2.19-r1/image/lib/ld-linux-x86-64.so.2 -> ld-2.19.so # ls -l /var/tmp/portage/sys-libs/glibc-2.19-r1/image/ total 24 drwxr-xr-x 3 root root 4096 Sep 16 16:48 etc drwxr-xr-x 2 root root 4096 Sep 16 16:48 lib drwxr-xr-x 2 root root 4096 Sep 16 16:47 lib64 drwxr-xr-x 2 root root 4096 Sep 16 16:48 sbin drwxr-xr-x 8 root root 4096 Sep 16 16:47 usr drwxr-xr-x 3 root root 4096 Sep 16 16:47 var And it works fine on multilib, while fails on no-multilib I can confirm it is this commit that introduced the problem: 10 Sep 2014; Mike Frysinger <vapier@gentoo.org> files/eblits/common.eblit, files/eblits/src_compile.eblit, files/eblits/src_install.eblit, files/eblits/src_test.eblit: Combine ABI for loops into one helper. I can confirm it is this commit that introduced the problem: 10 Sep 2014; Mike Frysinger <vapier@gentoo.org> files/eblits/common.eblit, files/eblits/src_compile.eblit, files/eblits/src_install.eblit, files/eblits/src_test.eblit: Combine ABI for loops into one helper. should be all set now in the tree; thanks for the report! Commit message: Move away from has_multilib_profile and rely on USE=multilib now that the flag should be sane across profiles http://sources.gentoo.org/sys-libs/glibc/files/eblits/common.eblit?r1=1.42&r2=1.43 http://sources.gentoo.org/sys-libs/glibc/files/eblits/src_configure.eblit?r1=1.1&r2=1.2 I can confirm that glibc successfully emerges on amd64-nomultilib(hardened)-profile now (and still does on multilib(hardened) :) ). Thanks for the fix!! *** Bug 523290 has been marked as a duplicate of this bug. *** |