I emerged glibc as part of standard system update a couple of days ago. It suggested I reboot after installing glibc, which I did. I was doing other things with the system yesterday, so I didn't notice the problem until today: ls, python (which means emerge, ebuild, qpkg etc, also) all fail, saying "ls: error while loading shared libraries: /lib/libpthread.so.0: invalid ELF header" (using ls as the example). Looking at lib/libpthread.so.0 shows a link to /lib/libpthread-0.10.so, which was 216 bytes. Running "file" on it says it's C code. (!!) Here's the contents of it: /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf32-i386) GROUP ( /lib/libpthread.so.0 /usr/lib/libpthread_nonshared.a ) Reproducible: Always Steps to Reproduce: I can reproduce the problem by running the 'ls' command (or any of several others). I can't reproduce the emerge of glibc, because emerge (probably via python) is broken by this also. I cannot produce an "emerge info" because this problem has broken emerge. (I did try.)
Sorry, forgot an important point. Last version of glibc in /var/portage seems to be... Whoops. There's something weird. glibc-2.3.3.20040420 and glibc-2.3.2-r9 have the same update time, and the file ~~~/temp/successful ALSO has the same time. Neither seems to be a link to the other. So I don't know what version I emerged. (I think there's a log file that tracks that - if somebody can point me to it, I may be able to find it from that.) I was not using any settings to get unreleased packages.
that would be normal if the file were /usr/lib/libpthread.so... this file is an ld script. is /usr/lib/libpthread.so a symlink? if so, that would explain the problem... and we might need to add a function to the pre-install phase of glibc to check for this.
I wish I could tell you. That IS the same file, but I panicked a bit and did a number of things (including compiling glibc as a binary package on another Gentoo system I have and manually (via tar) installing it), and I don't have that info anymore. I no longer think this is a glibc problem, or at least not directly. I installed my binary glibc-2.3.2-r9 package. It said that that would be a downgrade from glibc-2.3.3.20040420, and did it. Emerge -p says it wants to install glibc-2.3.3.20040420, and that I currently have 2.3.2-r9 installed. What's odd is that "emerge -p glibc" on my other Gentoo system says that 2.3.2-r9 will be installed. Running ACCEPT_KEYWORD="x86" emerge -p glibc on the problem system (called oboe) still says it wants to emerge 2.3.3.20040420. ACCEPT_KEYWORD="~x86" emerge -p glibc on oboe says it wants to emerge glibc-2.3.4.20040619-r1. Just to make things REALLY special, when I try to run "startx" (I was going to post "emerge info" now that I can, X won't start because it says it needs GLIBC_2.3.4. (!) (An "ACCEPT_KEYWORD="x86" emerge -p xfree" says it would emerge the same version of xfree I'm currently running.) I'm going to try an "emerge sync" and see if any of this improves. It didn't. I'm afraid that having "fixed" the problem, I've made it impossible to really fix it. My best guess at the moment is that I got a corrupt Portage structure from an rsync, and/or somebody fatfingered something and made glibc-2.3.3.20040420 unmasked for a few minutes. No idea why my system is so screwed up in the area now. If you can suggest anything for me to do that will help find and fix the problem for everybody, I'm willing (this time I'll wait a day or two before trying to fix all the other problems). If not, you might as well close this bug, because like I said, I'm not sure now that glibc was at fault at all - it may have been the victim of the problem, and just _appeared_ to be the culprit.
closing bug as invalid
