Your version of gcc probably doesn't support __thread. (According to the error). You need to update gcc first.

I tried that but it wanted to emerge glibc first.

Ahh.. perhaps I should first update gcc and then go about with glibc.. will comment out the glibc from my keywords and emerge gcc first.. why didn't I think of that before posting.. very well.. here I go..

Edit:

Hmm.. not that easy after all... I upgraded to gcc-3.4.4 first, but get the same error still..
well.. it's getting late.. probably check it out again tomorrow..

Your systems seems a bit screwed up. You are using the default-linux/x86/2006.0 profile but your CHOST is x86_64-pc-linux-gnu and you have ACCEPT_KEYWORDS="amd64 x86".

Since your'e using the x86 profile your CHOST should be i686-pc-linux-gnu and ACCEPT_KEYWORDS should be x86. On the amd64 profile however your CHOST should be x86_64-pc-linux-gnu and ACCEPT_KEYWORDS should be amd64 but your'e not using that. You can only choose one profile and never mix them like that. An you can't switch betwen 32 bit (x86) and 64 bit (amd64) profiles since they are different arches. I'm not sure it it's possbile to resuce your system. Reinstalling and doing it right from the beginning might be the best solution.

It also applies a bunch of patches, but it did not to that with my overlay (only change was the two comment marks to enable bdirect and hashvals). I read that sys-devel/binutils-2.16.1 included those patches, right? So I don't need the binutils overlay (2.16.90.x) right?

I'm confused... I guess there is more to it that copying the ebuild file to /usr/local/portage/sys-libs/glibc and edit it, and then run a ebuild digest on it...
will look a bit more on the official ebuilds...

Update 2: Ok. Now I copied the entire /usr/portage/sys-libs/glibc folder into /usr/local/portage/sys-libs/glibc, and enabled the bdirect and hashvals patches; ran a ebuild digest and it does not stop any more. Guess I needed all those files inside /usr/portage/sys-libs/glibc/files... ebuilding is not that easy after all.. will have to do some reading about that later I guess... starting (re)compiling now..

Last edited by Joffer on Wed Feb 22, 2006 12:18 am; edited 3 times in total

I'd like to know this too, I saw one post that talked about the system being dog slow after upgrading. Was that just the one poor poster?

Err, if you're referring to my comments, I was talking about Java being dog slow, not necessarily my system. This is on an x86 system as well and thus woudn't benefit as much, from the optimized amd64 routines that this patched glibc is tailored for. That said, after running a few basic benchmarks, nbench and a sat solver, I cannot say with any certainty that 2.3.90 is significantly slower or faster on x86 than 2.3.6. Java does remain slightly slower on my 2.3.90 x86 machine verses my 2.3.6 x86 machine, but at this point I'm inclined to attribute the performance to factors beyond glibc. My 2.3.90 amd64 machine is definitely faster in memcpy scores (as others have reported) than my unpatched amd64 machine, but both run about the same on the sat solver that I got from the other thread. However, my patched amd64 machine is dual core X2 and is much faster than my 2.3.6 amd64 machine, so again I can't arrive at any definitive conclusion. The only thing I can tell you for certain is give it a try and test it for yourself.

You're right, I was looking at PrakashP comments in the old thread and he was talking about a performance issue with the 2.3.90-snapshot and I didn't notice you were talking about specifically java in your post, sorry about that. I'm a way to fast reader . Doesn't seem to common though so I'll think about taking the plunge myself and check it out if there are some positive reports!

Keep in mind, I couldn't test whether this version of the SAT solver shows the same behaviour, but it should as the core is the same as the one with which I experienced the trouble. But if the problem went away - that's great.

(EDIT:)
Ok, I remembered on my home machine I had the broken version as well and quickpkg'ed it, so here you see the sympton with the böhm sat solver:

Nxsty, do I need to your your Glibc Overlay and Binutils Overlay to get Bdirect and hashvals to work? I was about to use your overlay (2.3.6-r2) but now I'm using 2.3.6-r3, where I have enabled the Bdirect and hashvals patches.. I'm also using binutils-2.16.1-r1 and gcc-4.0.2.

Yes, you get slow times wit glibc snapshots as well. It is not a compiler problem, as I first thought it is the case and tried 3.3.6, 3.4.5 and 4.0.2.

I'm not familiar with the sat benchmark or so.. higher score is better or worse? betterI presume?

It is run-time, so lower is better!

BTW: The problem with the snapshot glibc is in the headers, not the libs, because compiling to objects on non-broken system and linking on broken, leads to fast sat solver, and vice-versa. So are there some debug options enabled in the headers?

Yes, you get slow times wit glibc snapshots as well. It is not a compiler problem, as I first thought it is the case and tried 3.3.6, 3.4.5 and 4.0.2.

Yeah, my memcpy results are so much faster on my Athlons, though, I'm not sure what to think. I guess the best resolution would be to figure out what's going on with the glibc snapshot and this particular benchmark. I'll have to try and do some digging this weekend.

Quote:

BTW, it is interesting to see that the P4 is so bad at sat solving - probably due to its deep pipeline and sat is pretty unpredicatbly due to being np-complete.

What's also interesting is how much slower the supposedly faster (in clock speed) prescott core is than the northwood core.

Yes, you get slow times wit glibc snapshots as well. It is not a compiler problem, as I first thought it is the case and tried 3.3.6, 3.4.5 and 4.0.2.

Yeah, my memcpy results are so much faster on my Athlons, though, I'm not sure what to think. I guess the best resolution would be to figure out what's going on with the glibc snapshot and this particular benchmark. I'll have to try and do some digging this weekend.

Quote:

BTW, it is interesting to see that the P4 is so bad at sat solving - probably due to its deep pipeline and sat is pretty unpredicatbly due to being np-complete.

What's also interesting is how much slower the supposedly faster (in clock speed) prescott core is than the northwood core.

No real big surprize there.....

The netburst architecture was never intended to be anything more than a marketers dream... Clock speed sells... After all its a bigger number right? So it must be faster.....

BTW, it is interesting to see that the P4 is so bad at sat solving - probably due to its deep pipeline and sat is pretty unpredicatbly due to being np-complete.

What's also interesting is how much slower the supposedly faster (in clock speed) prescott core is than the northwood core.

The Prescott's pipeline is even deeper than the Northwood's, so it fits into the picture. (31 vs 20 stages, if I read sandpile.org correctly.) Athlon64 only has 12 stages for integers (which is what sat uses).

Nxsty, do I need to your your Glibc Overlay and Binutils Overlay to get Bdirect and hashvals to work? I was about to use your overlay (2.3.6-r2) but now I'm using 2.3.6-r3, where I have enabled the Bdirect and hashvals patches.. I'm also using binutils-2.16.1-r1 and gcc-4.0.2.

Glibc 2.3.6-r3 has the patches so you don't need my glibc overlay. You just need to enable them in the ebuild, but I guess you've already done that. Binutils 2.16.1-r1 has an older -Bdirect patch but lacks hashvals and dynsort so it's a better idea to use a overlay for it with the latest stuff.