> > I have been trying to compile a new kernel. (2.0.30) I have
> InfoMagics
> > Slackware 3.2 (6 CD set April 97) release.
> > I have been able to get pass "make dep" and "make clean", but when I
> > attempt "make zImage" it begins to compile but after awhile, the
> > following error message arrises:
> > -----------------------------
> If you type 'make zImage' again does it die with the same message in
> the
> same file (memory.o) ?
> If not, go to http://www.cdrom.com and download the Service Pack 2 for
> Slackware 3.2. It helped me.
Actually, I just worked my way through this compile quitting problem on
Slackware 3.3, so I doubt the patch to 3.2 will fix it. From watching
my "xload" I suspect the compiler eats up memory in some buggy way,
because xload goes to a high peak, then the compiler quits with an error
like the one you described. This is not a fix but a workaround that
will allow you to compile (I have used it successfully on kernels,
xservers, and wine):
1. At crashtime, note the name of the "object file" your compiler
crashed in (it has extension *.o) Then try to "Cntl-Alt-Fx" to another
virtual terminal, log in as root there, and run "ps." You will see
about three processes running in the gcc compiler. Kill only the last
one. This should enable you to switch back to the virtual terminal
you're compiling in -- if so, skip to (3). If not, or if you are hard
locked up and can't switch terminals:
2. Do a hard reset into Linux. You may be forced to run e2fsck as
root, but usually you won't have any dire losses.
3. Go back to /usr/src/linux and run "make zlilo" again (yes, without
doing make dep, make clean or any of that). This causes gcc to attempt
to pick up where it left off. Sometimes this will allow you to continue
compiling right from where you left off, and survive till the end.
However, sometimes you will crash again in the same spot. If so:
4. Run "make dep; make zlilo" (do not run make clean). Sometimes this
will get you over the hump. However, if you crash again at the same
spot, you will usually get an error message resembling "can't recognize
dma_buff.o -- file truncated." The "file truncated" message means (I
believe) that on your first pass you completed the object file enough
for gcc not to try to recompile it, but when it tries to link the files
it does not recognize it. Therefore:
5. Locate and remove the object file you crashed on. BE CAREFUL! The
object file is something you compiled yourself, so you can safely remove
it without altering your source code. However, only remove files with
*.o as an extension. NEVER remove a file with the *.c extension -- it
is part of your source code and you can't compile without it. Now:
6. Do "make dep; make zlilo" and you should be fine.
If this doesn't work, you have no choice but to start over. I've
tentatively decided that a memory usage bug is causing the crashes,
because I have 32 meg physical ram and 64 megs swap, so why would my
system be starved for memory. My previous experience has been that gcc
just slows down when it's starving. However, it's possible that you and
I share a configuration bug elsewhere in the system which is improperly
recognizing free memory. Do you notice, for example, that very little
swapping is going on, even when your memory load is high. I'm curious
if anyone else has this theory, particularly anyone who (unlike me)
knows what they're talking about.
by