I know this message shouldn't be here, but here's where all the geeks are. And I'm next to desperate.
I had two versions of binutils installed on my system - 2.17 from nxsty and 2.17.50.0.3 from portage. The first one was in actual use.
One damned moment I decided to try the 2nd version and did `binutils-config 2` from the shell. As you may guess, nothing ever worked after that.
I booted Knoppix, but I can't chroot to my / : "chroot: cannot run command `/bin/bash': No such file or directory". Not any other command may I run with chroot. And the executables are there.
I made it to /etc/env.d/binutils/ and re-pointed CURRENT to 2.17, hoping it would work - nope. Kernel panic, not syncing, no init found, specify on command line.. Well, I don't use initrd.

Is there any way out?????
_________________All In All Is All We All Are

I know this message shouldn't be here, but here's where all the geeks are. And I'm next to desperate.
I had two versions of binutils installed on my system - 2.17 from nxsty and 2.17.50.0.3 from portage. The first one was in actual use.
One damned moment I decided to try the 2nd version and did `binutils-config 2` from the shell. As you may guess, nothing ever worked after that.
I booted Knoppix, but I can't chroot to my / : "chroot: cannot run command `/bin/bash': No such file or directory". Not any other command may I run with chroot. And the executables are there.
I made it to /etc/env.d/binutils/ and re-pointed CURRENT to 2.17, hoping it would work - nope. Kernel panic, not syncing, no init found, specify on command line.. Well, I don't use initrd.

Is there any way out?????

That really doesn´t sound like a binutils problem. Even if you have two incompatible binutils versions installed you should be able to switch betwen them without problems. Something else must be wrong. Are you chroting the right dir? Is the root partition properly mounted? Is the filesystem ok?

thx4reply, nxsty
sorry for misinformating you, it was in fact a glibc issue. the new glibc from your overlay didn't sit well in my system, with both -Bdirect and --hashstyle enabled_________________All In All Is All We All Are

I have another sudden problem: tons of messages of the kind as above, e.g.:
8428: Warning: ignoring invalid out-of-map direct binding for symbol strcpy: 0xba0a9fc8

It's like I would have switched to new glibc, but I didn't. Everything was quite fine, incl. emerging stuff. The latest thing I can think of was a qt-3 upgrade: instead of portage's newly unmasked 3.3.6-r3 I emerged 3.3.6-r4 (still ~), replacing my own 3.3.6-r1. Could it be the problem???_________________All In All Is All We All Are

I would like to ask for a changelog of extra patches for glibc. You have indeed updated extra patches for glibc to 1.3 but what was changed since last version is unknown Do I have to reemerge glibc or even world in such case ?_________________HP Pavilion HDX9494NR [Intel Core 2 Duo X9000 | 20.1" Wide SXGA+ | 8GB Memory | 120 SSD + 500 HDD 7200rpm | Blu-ray Disc / Super Multi | NVIDIA GeForce 8800M GTS]

I would like to ask for a changelog of extra patches for glibc. You have indeed updated extra patches for glibc to 1.3 but what was changed since last version is unknown Do I have to reemerge glibc or even world in such case ?

Actually only the -Bdirect patch is new so you don´t need to recompile anything.

nxsty what is the current status of -Bdirect patch? Is it working with hash-style? And finally what is the future of -Bdirect patch? Is that patch going to be still developed or it will be dropped?_________________HP Pavilion HDX9494NR [Intel Core 2 Duo X9000 | 20.1" Wide SXGA+ | 8GB Memory | 120 SSD + 500 HDD 7200rpm | Blu-ray Disc / Super Multi | NVIDIA GeForce 8800M GTS]

yeah, I also second the question above. And, my "invalid out-of-map direct binding" errors are back, I think this happened after prelinking. Not all of them, though, e.g. _finalize doesn't appear now, but many others do, like strcpy, fwrite etc. _________________All In All Is All We All Are

yes, it's a prelink error, disappeared after I've undone prelinking. Can't get more details, apparingly there are some specific symbols affected. I was prelinking in a forced mode, prelink -avmRhf, now I'm going to try omitting -f and see what happens._________________All In All Is All We All Are

I just tried to play with the ebuilds for the little wild and this is what I come up with.

1) I tried to get new binutils to merge with bidirect flag, however unsuccesfully. then I tried to use it with just a bidirect patch and not the hash+dynsort patch. It failed co merge as well
2) What I tried to merge binutils with bidirect+hashvals patch only (not dynsort) and it merged properly !!! Using just a -Wl,-hashvals produced gcc error in configure that in can not create executables, but what I found out is that placing -Wl,-Bdirect and -Wl,--hash-style=both WORKED! Either I am insane and it is just my sight playing tricks on me or I have it acctually working (Bdirect and new hashvals patch)
3) I am not sure if this is important, but what I did is emerged the toolchain first without old hashlvals and then tried to emerge it with the new ne and it worked. I am almost at the end of emerge world and yet to see a problem

when i try to emerge the last toolchain overlay, it seems to depend on new previously masked by keyword kernelheaders.
why are these necessary, and what do i have to recompile after the new binutils, glibc and kernel headers ?
the compelte system ?