Compiling Problems - New Thread
 

Well, I've been trying to recompile the same on the 2.4.17 Kernel for two days now - and it totally bombs my @#$# system.. This is impossible. There is no way in hell you can successfully upgrade your glibc on new kernel headers without totally #@$@# everything up. I've followed all the HOW-TOs, numerous threads on other sites, etc, and it ALWAYS ends up rending my system useless trying to swap out library files. And from what I've been reading, no one else has been successful either.

Hell even if it did work, there would be so much clutter on the system, how the hell would you ever truely know if your not mix-matching different compiles of glibc with different headers.

It has to work. Honestly! :)
Where is it bombing specifically and the error messages? If David did it with 2.4.16 perhaps there is a quirk with the 2.4.17 headers or something...?

Sh*t, take your pic - what hasn't errored out or crashed... it's a god for saken mess dealing with glibc.

There are many people who have succesfully recompiled glibc. It isn't one of the easiest programs to compile so it can easily bomb out with errors. But if you really want someone to help you out you'll have to be a bit more specific on what it going wrong. Maybe post some of the output where it goes wrong. And maybe describe in which conditions you are trying to compile it, like on which machine, which kernel, etc....
I compiled glibc 2.2.4 with the headers of a 2.4.17 kernel so I doubt it's something to do with changes in the header files.

It's not the compile process that I can't get through - that's the easy part... it's the make install and swapping out of the old to the new - it bombs my system every single time.. all my links are messed up, my programs stop working, I start getting segmentation faults on everything, etc.

I've tried running configure with a --prefix=/usr and I've tried the default of /usr/local - same thing. It's like it half-ass installs everything.

Here's what I do:

I run configure like so:

./configure --prefix=usr --with-headers=/usr/src/linux-2.4.17/include --enable-add-ons=linuxthreads

This runs ... I then edit the config.make file and change the very end where it says, if I remember right under additional libraries, GDR=YES .. I change it to NO .. because the make process always bombs out at that point, and I read that you really don't need this to say YES.

I then run make and compile the new libraries.

Next, I remove all my old header files - by

mv /usr/include /usr/oldinclude
mkdir /usr/include
cd /usr/src/linux-2.4.17/include
cp asm-i386 /usr/include/asm
<basically copy everything out of the source include directory to /usr/include, with exception to all the other asm dirs>

Then I copy back my additional headers from other programs like ncurses or whatever else existed. If something already exists, it won't be copied back (new kernel headers)

cd /usr/src/oldinclude
cp -aRv /usr/include

Then I go back to the source of glibc and do a make install. The first time I did this, it bombed and said it couldn't find /usr/local/etc/ld.so.conf .... well duh, it's not there .. it's in my /etc folder ... so I just created a symbolic link from /usr/local/etc instead of setting the configdir env variable and starting all over again from configure... that seemed to work, and it went on. Then it choked again later in the make install check process I believe, it was running ldconfig and was looking for the primary libaries of ld-linux.so.2 in /usr/local/lib again... which again, of course it's not there, it's in /usr/lib .. why the hell it keeps looking in /usr/local I have no idea, because I set the --prefix to /usr ... well this last time I did the same and made a symbolic link from that location and continued make install once more, and it finished without a hitch...

None of my directories should have changed, and they didn't, so it all looked like it went - I reran ldconfig in case I need to reload the cache. And from that point on, nothing works... I can run some basic commands, but if I try to append paramters on to anything, it always bombs with a segmentation fault and dumps me back to the command prompt - and of course it won't even shutdwon or boot up again.

So - this is my second thread for this, I'll be surprised if anyone knows, I ususally never hear back.

Well first of all try the configure like this:

./configure --prefix=/usr \
--enable-add-ons \
--with-headers=/usr/src/linux-2.4.17/include

Then the step where you are moving your header files. Don't remove your whole /usr/include directory. There are so many other files in there that are needed to compile other programs. There is a specific directory there for the kernel headers called /usr/include/linux. On a lot of systems that's a symbolic link but it's best to copy the headers there directly.
The reason why it was probably looking in /etc/local is because you set the --prefix=/usr/local the first time. I don't know if you started from a fresh source tree after that. But it's wise to always do so.
Another thing you might want to do is:
unset CFLAGS CXXFLAGS
since you definetly don't want compiler optimizations.

I don't know how many howto's you've already read, but this one seems to cover the main steps:

http://www.linux.com/howto/Glibc2-HO...rimary-install

I've tried using the backslashes as well, no difference is made.
Yes, I am fully aware of this, that is why I copy it all back, with exception to the old kernel headers. You didn't read my last post closely enough, and I also saw your comment in my orginial thread regarding this. After I move the old /usr/include to /usr/oldinclude, I copy the NEW kernel headers into /usr/include, which puts the linux, asm, scsi, video, etc. back in /usr/include. Then I copy back the remaining headers from all the other programs. You DO NOT want a mixture of your old and new kernel headers. According to the glibc documenation, after it is compiled, it accesses the headers from /usr/include, not directly from /usr/src ... hence the reason you copy your new header files into /usr/include. Per Linus, it serves no purpose to have a symbolic link of /usr/src/linux pointing to your source directory of your current kernel in regards to glibc or any reason. The only exception to this might be where a 3rd party program tries to access this symbolic link. No, I have never specifically specified /usr/local - it defaults to there. And, on each new ./configure, I did start with a brand new source of glibc... aka - wiped the directory and untarred it again.
Never done this, I figure I should get it working before I add another factor to the equization.

Again, this whole process isn't the problem from what I can tell. It's the make install that isn't working, even though it says it has completed, it hoses everything up.

FYI, yes I've read that HOW-TO and it is so out of date it's not even funny. For one, it tells you to do, exactly what I'm doing to the /usr/include directory .. and two, you can't create symbolic links in the /usr/include directory, the glibc installation won't allow it.

Update - I did it all AGAIN .. this time without moving the /usr/include .. I just copied /usr/src/linux right over the top .. the whole install went without a single error... somewhat hopeful.. but as usual - after it's done.. everything I try to run, ends with the same error of "Segmentation Fault" .. nothing works. Same as before. Tried all the other stuff you suggested too .. didn't matter.

Just a question I just looked at the redhat site and it says 7.2 comes with glibc-2.2.4. What is the base distribution you are trying to replace the libraries on?
Probably doesn't make a difference but which compiler version are you using?
And the unsetting of the CFLAGS is something you should do before you run make. The CFLAGS variable is usually used for optimizations. But glibc can give segmentation faults if it's compiled with optimizations.
I'm not sure which version of libc you are trying to upgrade from. Because the older the version the more additional things you'll have to change before you get it all right. You could always try to compile it against the old kernel headers. This won't cause problems when you run a newer kernel.
Or try and install the new version in an alternate location and only let the programs that really need the new library use it.

Just so you don't mess up your system each time. You might want to run a make check before you do a make install.

Okay - I am not trying to upgrade .. it is the same version ... 2.2.4. All I'm trying to do is recompile against new kernel headers, because yes it does cause problems. I've already explained this ... twice if I remember right.

Oh ok sorry, I went back and read all the discussions you had before. It's just kind of hard to keep track if you keep starting a new thread.
I know I'm not an expert at this stuff and there are still many problems which stump me. I was just trying to give some ideas which might help you further.
I was just thinking about what you where trying to do. Actually you just ripped the guts out of the system replaced them with similar ones and then all the programs started crashing. Which is actually quite logical.
The header files provide the interface to a library, so if the header files change then the applications using the library will also have to be recompiled against the new header files. Basically if you change the library that drastically you will have to recompile all the applications using it too.
That's why we use static libraries for the programs here at work. Because it's a headache when the interface to the library changes and you only want to replace one of the programs using the library and not all of them.
As far as I understand you are trying to upgrade because you want newer functionality in some programs. Would it maybe be an option to compile a new glibc with the new kernel headers and place it in a different location. And only let some programs use the new library.
Well anyways I need to do some more research on the topic. Because I want to know how exactly each component links with the rest of the system. Kinda usefull when you start swapping out components.

Yea sorry - it's a bit confusing... I appologize if I come of harsh, I'm just so damn frustrated with this stupid thing I could puke.

BUT alas, I think I found the answer. After about the 100th time (no kidding) of reinstalling Linux and recompiling... I did an ' ldconfig -v ' afterwards .. and I noticed two of the same libraries of serveral things... mainly libc and ld-linux .. these both in /lib and lib/i686 .. I vagely remember /lib/i686 being in the default install of RH, so I wiped it... deleted the whole directory.. and whala, everything started working.. I think what was happening, is I had the two different compiled versions of the libraries, because the @#$#@ install put em in a different place... and the system was freaking out.

I knew it was gonna be something weird like that. None of these damn developers put crap in the same place for the same program. Argghh! They should at least give you a list of files that it generates and replaces, that would have make my job 10x easier.

Well glad to hear you finally found the solution. It always seems to work out just when you are about to give up after the 100th try. You really should build yourself an LFS system, especially since you compile everything from source anyways. You'll have no headaches of misplaced libraries because you choose where each one gets placed. That's really typical redhat to go and place there libraries in a different location.
I was reading up some more on the subject. It seems that there are very few applications which actually use the kernel headers directly. Most of them only use glibc. The ones that need the new feautures do link directly to the newer kernel header but those kind of programs are harder to build on a general system. What I gather from what you wanted, is that you needed new functionality which would be given to you if you recompiled glibc with the new kernel headers. To me it would only seem logical that glibc would need to be updated itself to provide extra stuff. And if the interface changed (the header files) then all the applications which use glibc would also have to be recompiled.
I might be totally wrong on all that. But it's hard to find a clear explanation about the whole situation. Maybe I should try going through the code to find out what it's all dependent on.