| Summary: | glibc upgrade to 2.4-r3 installed a corrupt linker script for /usr/lib/libc.so | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | patrick |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | major | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
libc.so - the modified version from Debian
libc.so - the one that comes with Gentoo (broken) log.bz2 libc.so the one glibc 2.4-r4 creates libc.so - now the entire file (from 2.4-r3) |
||
|
Description
patrick
2006-11-10 12:49:31 UTC
Created attachment 101624 [details]
libc.so - the modified version from Debian
Created attachment 101625 [details]
libc.so - the one that comes with Gentoo (broken)
that linker script you posted is corrupt and i highly doubt that's how it was installed you should run: qcheck sys-libs/glibc and verify your installation I reemerged glibc 2.4 r3 about 4 times and always presented me this broken libc.so. And still no change after the upgrade to r4 yesterday. qcheck gives me: Checking sys-libs/glibc-2.4-r4 ... MTIME: /usr/lib/libc.so * 1359 out of 1360 files are good with the one from Debian (the one which works) it shows: Checking sys-libs/glibc-2.4-r4 ... MD5-DIGEST: /usr/lib/libc.so * 1359 out of 1360 files are good with the gentoo original. I guess the MTIME is because I copied the backup of the original Gentoo version back (I used the Debian one in between to complete an update). That this in fact IS a problem is shown by the fact that I am not the only one whith this problem. If you looked at the forum thread, there are a lot of other people with the same problem. So please don't ignore this bug post. sorry I mixed up the two qchecks, now to make it clear, the gentoo one gives mtime and the debian one md5-digest. wrong ... most people who hit this error are using too old a version of binutils run `emerge glibc >& log` and post the log as an attachment the log file: ftp://madroach.dyndns.org/upload/log The file was to big for an Attachment (11MB). I hope it works this way. Always reopening the bug is rather wierd.... it's called compression ... run bzip2 on the file and post it as an attachment Created attachment 101823 [details]
log.bz2
Well then, the compressed log file.
and again, it looks like corruption ... your log file shows libc.so being created just fine:
(echo '/* GNU ld script';\
echo ' Use the shared library, but some functions are only in';\
echo ' the static library, so try that secondarily. */';\
cat /var/tmp/portage/glibc-2.4-r4/work/build-default-i686-pc-linux-gnu-nptl/format.lds; \
echo 'GROUP ( /lib/libc.so.6' \
'/usr/lib/libc_nonshared.a'\
' AS_NEEDED (' /lib/ld-linux.so.2 ') )' \
) > /var/tmp/portage/glibc-2.4-r4/image//usr/lib/libc.so.new
mv -f /var/tmp/portage/glibc-2.4-r4/image//usr/lib/libc.so.new /var/tmp/portage/glibc-2.4-r4/image//usr/lib/libc.so
Created attachment 101920 [details]
libc.so the one glibc 2.4-r4 creates
Well, two things, the libc.so I posted before missed the last to characters, I probably missed them when copying the libc.so. There were two )) at the end, sorry for that.
The libc.so that 2.4-r4 creates is an little bit different libc.so, I hope I get the entire file this time.
Created attachment 101921 [details]
libc.so - now the entire file (from 2.4-r3)
ok, those files are nothing like the one you posted originally and in this case, your toolchain is too old to handle the as needed syntax make sure your binutils/gcc are up-to-date -> not a bug in glibc *** This bug has been marked as a duplicate of 126032 *** Well then, I guess you found the solution to my problem, thanks. Sorry for all the mess I created with this bug. |
