Ok - well I've managed to completly @#$@ my system attempting to upgrade glibc ... and recompile using new kernel headers. Here is what happened .. it has been my experience that if you try to install a new program from source over an existing RPM installation, it screws everything up, because it never fails, it always mixs versions of the same program.

So I attempted to remove the old GLIBC RPMs that came with RH that were compiled with old kernel headers.. when unbenounced to me, the stupid RPM includes all the system commands with it. So now I can't do anything in order to recompile the new GLIBC ..

I'm stuck - I can't reinstall, I can't compile I can't do crap.. how the hell are you supposed to upgrade and make a clean system if you can't get rid of an old version first.

It wouldn't have done any good in my mind to remove it after compile either, because the system would have been cached for the glibc in a different location and hosed anyway. I'm still baffled as to why RH bundled all the extended system commands with the glibc RPM .. I just got through checking which libraries those use, and they use ELF libraries and such, nothing to do with glibc.

Maybe I'm missing something here??

No one knows how to properly upgrade glibc with new kernel headers?

first off, what is the reason you need to upgrade ??

It's a long story - and not sure I want to go into that at the moment. In a nut shell, if you upgrade to a newer kernel, you need to recompile your glibc against the new kernel headers in order to take advantage of the newer features, not to mention you break other things by running a compiled version of glibc with older kernel headers than what you're currently using... I really am not interested in getting in a huge debate over it. But if you can offer advice on how to upgrade the glibc with bombing your entire system, that would be nice.

not sure. i usually use only source files to install. but unless someone has an answer before me, i'll look into it as i have never had to update my glibc, only installed it during my LFS and that wasn't necessarily a upgrade..

Yea I'm the same way -- I always use source files ... It's pretty typical of me to install RH and rip out all the stupid RPMs and install the latest via source.

Well I may beat you to an answer .. dunno.. I had to reinstall from scratch again, I really screwed up the OS big time, no way to get out of it. So now I'm trying again.. if RH would have installed GLIBC from source as opposed to binaries, it wouldn't have happened... but those damn precompiled binaires really cause problems on some things, essepecially in this case.

Okay - well I've done a 'configure' and a 'make' on the glibc source pointing it to the new 2.4.17 kernel headers and it's ready to be installed.. but according to the directions I've found for compiling glibc, I now have to get rid of the old /usr/include directory containing my old kernel header files and now move or symbolicly link the new kernel headers to /usr/include.... simple enough right? Not quite....... how the heck do I easily retain all the additional header files that have been put into the /usr/include directory from other programs... like ncurses, etc.?? To tell you the truth, I'm not sure what belongs to what.

I'm stuck at this point.. I could just always move it all.. but if it breaks.. it's not a simple matter of fixing it.. I basically have to reinstall Linux again due to the damage that it does.

I have a related question and since you're usually using sources instead of RPMs maybe you can answer it. How do you usually upgrade your software? If you have some version installed from the source do you just install the new version on top of it, or do you have some way of removing all old files.

And how do you keep track of the dependencies?

In most cases you can just upgrade on top, considering the developers use the same paths repeatedly (unlike RPMs). I've found a few cases in which this wasn't true, but it's very rare in my opinion. As far as dependencies... what don't you know? I'm not sure I understand your question, if a program has a depencency, it ususally states it out pretty clearly in the INSTALL or README files... I know whether or not I have those libraries or what-not installed, because I know how my system is setup, therefor I know if I need to install them or not... if for some reason I don't know, I can do a simple search and find out if I have it or not. RPMs in my opinion are a pain in the ass. They continuiously report false/wrong dependencies.. saying you don't have something, when you do.. not installing programs properly, and can be a nightmare to upgade some programs. I can't count how many times I've had to rip out an RPM because it woudn't work right and go download the source and compile it myself.

Someone I'm sure is going to argue with me, but that is fine, these are my experiences, if someone has had better luck, that's great.. I just prefer to do it this way unless I figure out something better or new between now and then.

Just a note about the /usr/include directory. You shouldn't remove the whole /usr/include directory. I guess you found out why. There should be a subdirectory there called linux. This is where all the kernel headers are placed. It's best to copy the kernel header files to this location. But on a lot of distributions /usr/include/linux will still be a symbolic link to /usr/src/linux/include which in some cases can cause problems.