After the upgrade to glibc 2.4 gcc fails to run with error: /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../../i686-pc-linux-gnu/bin/ld:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../libc.so: file format not recognized; treating as linker script /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../../i686-pc-linux-gnu/bin/ld:/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/../../../libc.so:5: syntax error collect2: ld returned 1 exit status Well I found the problem and thus the solution, the problem was /usr/lib/libc.so. I copied the libc.so from another computer (debian) and now it works. (I don't know what I did, nor why it helped.) This is a hack and thus has to be fixed. http://forums.gentoo.org/viewtopic-t-495245.html look here for more details.
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.
