prelink renders ld-2.13.so unusable so that any application using it will segfault. This is a regression from glibc 2.12+ Reproducible: Always Steps to Reproduce: 1. prelink -amvR system 2. type 'ls' 3. I blacklisted /lib/ld-*.so for what makes prelink actual not prelinking _any_ application.
[I] sys-libs/glibc Available versions: (2.2) [P]2.2.5-r10!s 2.5-r4!s **2.5.1!s 2.6.1!s (~)2.7-r2!s 2.8_p20080602-r1!s 2.9_p20081201-r2!s (~)2.9_p20081201-r3!s 2.10.1-r1!s 2.11.2-r3!s (~)2.11.3!s (~)2.12.1-r3!s (~)2.12.2!s (~)2.13!s {build crosscompile_opts_headers-only debug gd glibc-compat20 glibc-omitfp hardened multilib nls nptl nptlonly profile selinux vanilla} Installed versions: 2.13(2.2)!s(09:11:40 06.02.2011)(gd glibc-omitfp nls -crosscompile_opts_headers-only -debug -hardened -multilib -profile -selinux -vanilla) Homepage: http://www.gnu.org/software/libc/libc.html Description: GNU libc6 (also called glibc2) C library [I] sys-devel/prelink Available versions: 20100106 (~)20100714 (~)20101123 Installed versions: 20101123(21:27:56 28.12.2010) Homepage: http://people.redhat.com/jakub/prelink Description: Modifies ELFs to avoid runtime symbol resolutions resulting in faster load times [U] sys-devel/gcc Available versions: (2.95) 2.95.3-r9 (~)2.95.3-r10!s (3.1) 3.1.1-r2 (3.2) **3.2.2!s 3.2.3-r4 (3.3) (~)3.3.6-r1!s (3.4) 3.4.6-r2!s (4.0) ~*4.0.4!s (4.1) 4.1.2!s (4.2) (~)4.2.4-r1!s (4.3) (~)4.3.3-r2!s 4.3.4!s (~)4.3.5!s (4.4) (~)4.4.2!s 4.4.3-r2!s (~)4.4.3-r3!s (~)4.4.4-r1!s 4.4.4-r2!s (~)4.4.5!s (4.5) (~)4.5.1-r1!s (~)4.5.2!s {altivec bootstrap boundschecking build d doc fixed-point fortran gcj graphite gtk hardened ip28 ip32r10k java libffi lto mudflap multilib multislot n32 n64 nls nocxx nopie nossp nptl objc objc++ objc-gc openmp static test vanilla} Installed versions: 4.4.5(4.4)!s(02:53:52 19.10.2010)(fortran gcj gtk mudflap multislot nls nopie nptl objc objc++ openmp test -altivec -bootstrap -build -doc -fixed-point -graphite -hardened -libffi -multilib -n32 -n64 -nocxx -nossp -objc-gc -vanilla) 4.5.1-r1(4.5)!s(23:06:27 20.12.2010)(fortran gcj graphite gtk mudflap multislot nls nopie nptl objc objc++ openmp test -altivec -bootstrap -build -doc -fixed-point -hardened -libffi -lto -multilib -n32 -n64 -nocxx -nossp -objc-gc -vanilla) 4.5.2(4.5)!s(15:47:44 28.12.2010)(fortran gcj graphite gtk mudflap multislot nls nopie nptl objc objc++ openmp test -altivec -bootstrap -build -doc -fixed-point -hardened -libffi -lto -multilib -n32 -n64 -nocxx -nossp -objc-gc -vanilla) Homepage: http://gcc.gnu.org/ Description: The GNU Compiler Collection
glibc was compiled using GCC 4.5.2
I believe you'll find this bug is a duplicate of this one http://bugs.gentoo.org/show_bug.cgi?id=353814 which was filed earlier this morning. I posted about this issue in the forum on this post http://forums.gentoo.org/viewtopic-t-863297-highlight-.html You are lucky that this didn't hose your system. Several of us have had bash, our DE, and most other apps crash which forced us to hard reboot. Upon rebooting the kernel panics rendering the machine useless until chrooting in from a rescue disk to make repairs. A very nasty glitch indeed.
*** This bug has been marked as a duplicate of bug 353814 ***
Marc, please do not cc arches yourself. If you do not know how the system works, let wranglers do their jobs. Thanks.
I just accidentally used ARCH instead of HARDWARE what I probably meant in the first place. No need to sound rude!
(In reply to comment #6) > I just accidentally used ARCH instead of HARDWARE what I probably meant in the > first place. No need to sound rude! What else can I do to not sound rude apart from using basic terms of politeness like "thanks" and "please"? It was not meant to sound rude, but the arch alias have a meaning which is not to fix any bug in packages. As people get it wrong quite often it is annoying, because it causes emails to at least 20 people, if you add amd64@g.o to at least 50. On an average day I get 50-100 emails for the x86 alias, where I have to skim through all of them (and Gentoo is not what pays my bills, so I do it in the evenings). Just you get an idea why "impatient" bug filers (as much as we want to be informed about problems) can be painful.
