Re: Can someone spare some CPU time?
> > Surely I know and understand but if it was a single, simple error that can be
> > described clearly it would be as easy as you wrote. The problem was (and is)
> > that - let's say - one configured a kernel config suitable for the destination
> > hardware. Starts making and the build process breaks on a source belonging to
> > "option A" so one goes to the config and turns this option off. Goes back to
> > 'make' and then it breaks at "option E". He turns this one off too and in that
> > case the compile breaks at another thing and so on... It simply looked to me
> > that it is far from compilable state and thus I thought that either it is so
> > or I am missing something. It seems not to be a single, hardware dependent
> > problem that can be reported that easily.
>
> But what does it do? What seems like a bunch of random, unrelated errors
> to you may be obviously connected for someone more familiar with these
> things.
Two things: if you did indeed use the m68k source, from sunsite.auc.dk (or
ftp.mac.linux-m68k.org for Mac) and you get compile errors either your
.config is utterly broken (post it here for people to look at), or your
problem is rather related to sporadic hardware failures that either
corrupt data on your disk or confuse the kernel. gcc uses quite a chunk of
RAM and tends to expose bad RAM that wasn't detected otherwise.
If bad RAM is your problem, gcc should die with signal 11 or some other
signal. If you get other messages, post a copy here (or on linux-m68k).
Second: all of this assumes you did the suggested make dep; make clean
after make config (and I wouldn't trust make menuconfig or make xconfig to
report the correct date on 2.0.36, much less to generate a sensible
.config).
Michael
Reply to: