in fact you could try to chroot with bb (if you have one - if not it surely could be downloaded somewhere, it should be linked static) and try again with the rebuilding and see what's failing next._________________"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack

if you still would like to try to save the installation
delete
/lib/tls/
in fact go and look /var//db/pkg/sys-libs/glibc-2.3.6-rX/CONTENTS
delete all the files, which are listed there and after that re-extract 2.4_________________"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack

Alright I'm back in business. Turned out /lib/tls was leftover stuff from 2.3.x that had to be destroyed so 2.4 would work again. Of course I'm definitely stuck with 2.4, but at least with Xorg recompiled I seem to be going OK. For now.

BTW busybox kicks ass. I was surprised that even its tar implementation had bzip2 support.

just letting you guys know, I am doing emerge -e world to see if this fixes my xorg locking up.

I use to get the NVRM XVID lock up problem (mouse moves but X takes up all available cpu resource). Got that fixed, the system was stable, and then glibc 2.4 broke it. emerging xorg didn't seem to help. let see if emerge -e world fixes my problem.

After emerging glibc-2.5, I can't seem to be able to compile mozilla anymore. I did a emerge -eD --world to solve the issues I had with updating to glibc-2.4. Now these packages would not build for me, (but I'm not sure if it's related to the glibc-2.4 upgrade):

* emerge mozilla quits with this error message, it builds fines on my other glib-2.3.5 box

that isn't what the bug report was about, so your presumptions about why the bug was closed aren't quite accurate.

on the suject of dependencies, you are absolutely correct. coreutils 5.94 is not required to compile glibc 2.4 or to run it, so its not a dependency for glibc 2.4.

on the other hand, if you deploy glibc 2.4, the deployment of coreutils 5.94 is absolutely necessary in order to have a functional system. unfortunately, this information isn't provided for the user.

one of the biggest deficiencies in Gentoo is the myopic vision among both developers and seasoned users alike about what constiutes a dependency. how anyone sees this depends upon whether their focus is on building one specific package or whether their focus is on building one functional system. if you look at what is required to build an individual package you get one answer, while if you look at what is required to build a functional system you get a different answer. unfortunately, the conceptual design of portage successfully addressed the first problem but failed to even conceptualize the second.

the answer doesn't lie in patronizing other people about mixing stable and testing branch packages. it doesnt' make sense to limit the scope of one's vision that way. some people need to lift up their eyes. this is about being able to see the forest for the trees.

it would be more meaningful to revise the conceptual model of what constitutes a dependency. the term "hard" dependency could be used to encompass the current definition of packages that are required to build other packages. the term "soft" dependency could be used to define packages that must be used with other packages in order to ensure functionality of the system. by accounting for both types of "dependencies", one could successfully eliminate all of the deficiencies inherent in using Gentoo / Portage.

in the big scheme of things, it all revolves around whether or not one's philosophical objective is limited to maintaining an existing solution in its present state or whether one's philosophical objective focuses upon conceiving a better replacement for it. the absense of seeing the big picture in designing Gentoo is precisely what make gentoo difficult to use for many people. its precisely what fubars a user's migration from one toolkit to another. its precisely what keeps a distribution stagnant instead of moving forward. there's definitely room for improvement here. but then alot of people so focused on understanding Daniel Robbins' vision that it never occurs to them to look beyond it._________________.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks

There seem to be a few threads I could join, so I hope this one is suitable.

I came up on the 'must use nptlonly' issue, followed by the 'missing or too old: gcc' issue. After reading as many recent gcc-4 threads as possible, I unmasked and emerged gcc-4.1.0 - but now the 'missing or too old: gcc' condition recurs! Here's my whatsit...

Other info: the box is a server with no DE installed, hence the absence of the X use-flag (though X is merged, I just don't use it). The abundance of media-related USE-flags is from my (ultimately fruitless) attempts to run a vlm streamserver.

I apparently have three versions of gcc installed: 3.4.5-r1, 3.3.6 and now 4.1.0. Could this just be a config issue?

After emerging glibc-2.5, I can't seem to be able to compile mozilla anymore. I did a emerge -eD --world to solve the issues I had with updating to glibc-2.4. Now these packages would not build for me, (but I'm not sure if it's related to the glibc-2.4 upgrade):

* emerge mozilla quits with this error message, it builds fines on my other glib-2.3.5 box

that isn't what the bug report was about, so your presumptions about why the bug was closed aren't quite accurate.

on the suject of dependencies, you are absolutely correct. coreutils 5.94 is not required to compile glibc 2.4 or to run it, so its not a dependency for glibc 2.4.

on the other hand, if you deploy glibc 2.4, the deployment of coreutils 5.94 is absolutely necessary in order to have a functional system. unfortunately, this information isn't provided for the user.

one of the biggest deficiencies in Gentoo is the myopic vision among both developers and seasoned users alike about what constiutes a dependency. how anyone sees this depends upon whether their focus is on building one specific package or whether their focus is on building one functional system. if you look at what is required to build an individual package you get one answer, while if you look at what is required to build a functional system you get a different answer. unfortunately, the conceptual design of portage successfully addressed the first problem but failed to even conceptualize the second.

the answer doesn't lie in patronizing other people about mixing stable and testing branch packages. it doesnt' make sense to limit the scope of one's vision that way. some people need to lift up their eyes. this is about being able to see the forest for the trees.

it would be more meaningful to revise the conceptual model of what constitutes a dependency. the term "hard" dependency could be used to encompass the current definition of packages that are required to build other packages. the term "soft" dependency could be used to define packages that must be used with other packages in order to ensure functionality of the system. by accounting for both types of "dependencies", one could successfully eliminate all of the deficiencies inherent in using Gentoo / Portage.

in the big scheme of things, it all revolves around whether or not one's philosophical objective is limited to maintaining an existing solution in its present state or whether one's philosophical objective focuses upon conceiving a better replacement for it. the absense of seeing the big picture in designing Gentoo is precisely what make gentoo difficult to use for many people. its precisely what fubars a user's migration from one toolkit to another. its precisely what keeps a distribution stagnant instead of moving forward. there's definitely room for improvement here. but then alot of people so focused on understanding Daniel Robbins' vision that it never occurs to them to look beyond it.

I havn't written an e-build in 3 years or so, but when I was doing it, depend was for things that are both run time and compile time dependancies, cdepend for compile time deps, and rdepend for run time deps.

This goes again and again, but the solution to this problem is that the poor soul, who decides to deploy a ~arch glibc on a stable system, should alone resolve the problems created - as is simple as this.
The developers could not depend on ~arch (in meads of sth like DEPEND="~arch"), as this is the correct solution in this case.
I could understand mixing ~arch gnome or kde with stable system, but if you are using vital parts of the system, which are marked ~arch, then you run a full ~arch system, or you help yourself._________________"I knew when an angel whispered into my ear,
You gotta get him away, yeah
Hey little bitch!
Be glad you finally walked away or you may have not lived another day."
Godsmack

(...)
on the other hand, if you deploy glibc 2.4, the deployment of coreutils 5.94 is absolutely necessary in order to have a functional system. unfortunately, this information isn't provided for the user.
(...)

on x86 and I've not encountered any significant trouble so far, either compiling or running stuff. GCC is at 3.4.5-r1. Could you elaborate a bit on what exactly makes my system non-functional, so I can fix it? _________________0mFg, G3nt00 r0X0r$ T3h B1g!1111

Did a new install - I mean a new system from scratch - took me 2 days with minimal compile errors using gcc-4.1.0 and glibc-2.4

Using unstable ~x86. The errors I found were:

* objc-gc support needs libgc as a dependency, have to emerge libgc manually
* even with libgc it didn't compile (I didn't waste time trying to compile it again)
* amarok-1.4 needs to have in libdc1394 dependency (1.0) the CLK_TCK changed to CLOCK_PER_SEC (glibc 2.4 removed the macro so I had to edit grab_partial_image.c manually)
* nx-x11 needs to have rmake, gccmakedep and imake as proper dependencies
* Vmware 5.5x needs to be fixed for kernel module compilation with gcc 4.1 (-Werror needs to be removed)

...
* amarok-1.4 needs to have in libdc1394 dependency (1.0) the CLK_TCK changed to CLOCK_PER_SEC (glibc 2.4 removed the macro so I had to edit grab_partial_image.c manually)...

grab_partial_image.c: In function `main':
grab_partial_image.c:216: error: `CLOCK_PER_SEC' undeclared (first use in this function)
grab_partial_image.c:216: error: (Each undeclared identifier is reported only once
grab_partial_image.c:216: error: for each function it appears in.)

Ok I've been playing around with the new GCC 4.1 compiler and Glibc 2.4 and after reading through the forums I got the system to compile cleanly, but emerge -e world always fails at libsdl. I've got other packages to compile simply by upgrading to the latest versions (libgii, libggi) but when compiling the latest libsdl, I get the following errors

I don't know if this is related or not but on emerge -uDN world it wants to install fontforge, which also will not compile. I found that fontforge is now a dependancy of Wine so I was able to update my system by just cleaning out wine (I have a windows partition so it's not necessary right now) fontforge fails with this

I believe thier are some packages that will not compile without -ffriend-injection in the CXXFLAGS. Are you suggesting I use different make.conf profiles for different packages? if so please let me know if there is an easy way to do this and cleanly comile the whole world tree_________________Occupation: Professional Slacker
Hobbies/Interests: Open Source Aficionado since 2005