I have gcc 3.2 and I'm attempting to compile gcc 4.2.1 on an AMD k6-2 and it's very slow. Every time I try and compile my system freezes but not right away sometimes after 8 hours of compiling. It always freezes when compiling different files, so it's not trying over 1 line of code and freezing.

I want to know is there a way I can compile gcc in steps and stages so if my system freezes I can pick up from where I left off?

Ummm… by the nature of make, doesn’t it pick up where it left off?

As GCC is part of a three-piece toolchain including GCC, GLIBC and BinUtils, it isn't likely that compiling GCC by itself will accomplish anything useful for you, except perhaps to screw up your running compiler.
Have you identified the source of the lockups?

Compiling a new toolchain is no easy feat, and for the most part, if something goes wrong, doesn't work, or the system crashes, you need to start over clean from the beginning. If you just go ahead and start building a toolchain on your running system out of the blue, it will sooner or later overwrite parts of the toolchain that's actually running on your machine, and totally screw everything up. This happened to me several times while I got a handle on what I was trying to do, and I ended up reinstalling large portions of my OS (specifically the toolchain pieces and everything else connected or related to it).

For reference, look up the tutorials on LFS and DIY (Linux-from-scratch and Do-It-Yourself Linux) to see what I mean about the toolchain.
I also have a rather long thread around here called 'ReCompiling & Optimizing Slackware' or something similar to that, where I am in the process of doing just that same thing.

Usually one compiles a toolchain from within a CHROOT environment, where the work you are doing cannot affect your running system, and is indeed done in a three stage process. In between successful stages of the whole process, you could stop, save/backup the state of things, and resume later from that backup point if the next stage crashes, but otherwise, if the system crashes during the compilation, the only reliable way to start again is to start over.

Also, as a side-note, it has been reported that compiling things like the toolchain on old slow machines is VERY unreliable, and often fails, perhaps due to excessive resource consumption, or simply 'not enough computing power'.

GrapefruiTgirl, thanks for the information. I'll definitely search for your other posts.
I've compiled and installed binutils 2.17 (I previously had 2.12).
I've just successfully compiled gcc 4.2.1 by using the --disable-bootstrap --disable-libgcj options.
I guess I'm one of those unlucky people compiling on an old slow pc and I'll have troubles.
My goal is to compile PHP5 which requires libxml2 2.6.x and I only have libxml2 2.4.x For libxml2 2.6.x I need glibc2.6.x and I only have glibc2.2.5

I compiled gcc with --program-suffix=-4.2.1 so the binary is gcc-4.2.1
I'm planning on linking /usr/bin/gcc to /usr/bin/gcc4.2.1 (My old version of gcc is 3.2 and is backed up as gcc3.2)
Will just switching to a new version of gcc cause problems for me? Or is it installing glibc2.6.x that will break my system. I'd like to install glibc2.6.x to a different directory and just specify it in the configure when compiling libxml2 and PHP5? Would that work?

Sounds like you have some understanding of how the toolchain situation works, which is good.

I to believe it IS glibc which breaks the system when compiled in-situ, because it overwrits the running version. I have compiled GCC alone, and it went fine, granted it didn't take 8 hours but only about 30 mins.. It went fine, but then I learned more about the toolchain as a whole, and decided it was basically useless having a new GCC without the other parts, so I then went about learning how to do the whole thing properly.

As for the 3 stage compile, the way it works is like this (basically) : GCC, GGLIBS and BinUtils all depend on each other. At each stage of the build, a little more of the new parts, are integrated into the compile process. So, at the start, you compile STAGE-1 of the first item, using your running system.
By the end of the process, you will have compiled the new GCC, using ITSELF (the new one) at the last stage, and your running system's toolchain will have little or nothing to do with the build at all.

I'm perhaps not explaining this very clearly, but I am using the DIY method of rebuilding my Slackware toolchain, and it explains **pretty** well how to go about the 3-stage process of making a toolchain. I've had to fill in a couple little blanks, but overall, with a LOT of patience, I have gotten it to work.

I am still adjusting to a brand new machine here, after my old motherboard 'died' during compiling never to live again. So, I am definitely rusty for the moment, but as I recall, to answer your very last question, it IS possible to have two glibc's on a machine (or maybe more) and simply point other applications or compile-jobs at them to get the benefits. I'd venture a guess however, that recompiling your running toolchain properly and integrating it into your running OS, will ultimately make your proposed PHP job a lot easier in the end.

Here's my thread I referred to:http://www.linuxquestions.org/questi...d.php?t=558415

Thanks for posting a link to that thread, GrapefruiTgirl. Great stuff.