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

I get this when building the new binutils-2.17.50.0.5 build from your overlay. the bdirect useflag is enabled. This is on amd64.

Bump, same here. Binutils-2.17.50.0.5 from official tree emerged OK.

same error trying to compile with bdirect flag binutils 2.17.50.0.5. without bdirect flag it compiles though, but having the whole system already bdirected i woudl like to stay with it. strange that this error is still there. (Read about it nearly one month before _________________quot licet iovi non licet bovi

Hate to break it to you, but you're missing the glibc patch for -bdirect.

I'm glad that You found the time to take a closer look at the patchset. I must say that from the beginning I was thinking it is to good to be true But if this is true how come neither opensuse patchset does not have it nor the toolchain overlay based on them. Maybe it is not needed? (I know -bdirect is not in the official glibc) When I first switched to -Bdirect stuff I noticed quite a jump in app loading time and I must say it sure didn't decrease now at least visually while I am using these two._________________Sky is not the limit...

I'm having difficulty pulling in the glibc patches/files. I figured i should wait a few days before posting to see if the issue would resolve itself, but alas it has not. Anyway, i browsed through to the online directory that hosts the files and the site is functioning fine, the files just aren't there. Could anyone perhaps offer up these missing files? Particularly 'glibc-2.5-patches-1.2.tar.bz2

Thanks for the link, but i fixed the problem shortly after posting. I pulled the files for the portage glibc and saw that the patches were at 1.3, so i changed the overlay ebuild from 1.2 to 1.3 and it worked

Thanks for the link, but i fixed the problem shortly after posting. I pulled the files for the portage glibc and saw that the patches were at 1.3, so i changed the overlay ebuild from 1.2 to 1.3 and it worked

i am recompiling the gentoo standard glibc and binutils as the key people embedding changes to this builds seem to have lost interest and we have open issues with amd64 for long time now.
thanks for the great compilation nxsty though and the time spent to put all together !_________________quot licet iovi non licet bovi

I don't feel like I'm on the bleeding edge with a glibc that's more than a month old!

yes, i felt also. so, i create with cvs-head by composite nxsty ebuild.
it is completely same patches from last 1022-r1.ebuild exclude branch update.
but minor sync with portage on ebuild detail strings.

here also works fine for few days (compiled with 4.2.0), but I can not compile it (and any other glibc) with 4.3.0
thx pal_gene_________________nBVCXz
zen-kernel (bfq compcache) | /tmp -> tmpfs | ext4 | zsh | xfce | schedtool

i modified to pass glibc testsuite and somehing wrong against gentoo glibc-compat.

FEATURES="test" will pass now.
elf/check-localplt test needs some modify for glibc-ssp-compat if only don't have USE="glibc-compat20".
so, scripts/data/localplt-{i386,x86_64}-linux-gnu.data was changed in this ebuild.
But i can't test on amd64.
*additional export func.
0010_all_glibc-ssp-compat.patch:__stack_chk_fail
6901_all_2.4-amd64-strings-20061210:__bzero

FEATURES="test" USE="alltest" will pass with required toolchain.

testing_note

Code:

you can test glibc by glibc testsuite set enviroment FEATURES="test" when emerging glibc.
skip test nptl/tst-cancel1 by default. you can test nptl/tst-cancel1 with USE="alltest".

WARNING! During test, system become high load on some test.

-nptl/tst-mutex5,tst-cond*:
failing sometimes randomly for me.
it is timing problem, i think it depend on kernel timer or preemptible or scheduler.
application must engage timing can use rt(realtime) code, thus it should be harmless.
see http://www.osdl.org/developer_bugzilla/show_bug.cgi?id=34

- nptl/tst-cancel1
stop with "Didn't expect signal from child: got `Aborted'"
this seem to fail with not supported toolchain (gcc,binutils and other debugging with gdb).
DW_CFA_val_{offset{,_sf},expresion} is supported since gcc-4.2, binutils-2.17.
see http://sourceware.org/ml/libc-alpha/2006-09/msg00039.html