Re: Segfault compiling kernels
> On Fri, 2001-12-28 at 17:37, Michel Lanners wrote:
> > I have done a new install of Debian 'woody' on a beige G3 here at work. Some slight
> > quirks on install, but it generally works.
> > However, I tried to compile kernels, and all I get is segfaults:
> > mlan@snow:/usr/src/linux$ make dep
> > gcc -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -o scripts/mkdep scripts/mkdep.c
> > make -C arch/ppc/boot fastdep
> > make: Entering directory `/usr/src/linux/arch/ppc/boot'
> > /usr/src/linux/scripts/mkdep -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common -D__powerpc__ -fsigned-char -msoft-float -pipe -ffixed-r2 -Wno-uninitialized -mmultiple -mstring -fno-builtin -D__BOOTER__ -I/usr/src/linux/arch/ppc/boot/include -- > .depend
> > make _sfdep_chrp _sfdep_common _sfdep_images _sfdep_lib _sfdep_mbx _sfdep_pmac _sfdep_prep _sfdep_tree _FASTDEP_ALL_SUB_DIRS="chrp common images lib mbx pmac prep tree"
> > make: *** [fastdep] Segmentation fault
> > make: Leaving directory `/usr/src/linux/arch/ppc/boot'
> > make: *** [archdep] Error 2
> > It seems make is to blame here??
> > I tried to compile something else (asclock; small program); compiling and running are OK in
> > that case.
> > Anyone seen something like this? My home machine (woody as well) doesn't have these
> > errors (at least not prior to the last dist-upgrade). My install here has nothing
> > special otherwise; just plain up-to-date woody.
> > Running Debian-installed programs is no problem; I have not seen anything segfault
> > (certainly not general problems like bug in libc).
> > Kernel source is kernel.org official kernel; both 2.4.16 (which compiled OK on an i386)
> > and 2.4.17 produce the same symptom.
> What kernel are you running?
Either 2.2.19 (Debian install kernel) or 2.2.18-presomething (LinuxPPC 2000 Q4 install kernel).
Since I have not been able to compile a 2.4 kernel, I'm stuck with whatever kernels I can find
that have Sym53C8xx compiled-in, since my boot disk hangs off that controller (the one bundled
by Apple, built by Atto).
> Spurious segfaults can only really be caused by libc, the kernel or
> hardware, or am I missing something?
I don't know if you can call these 'spurious', since they _always_ happen on kernel compile,
but (so far) on nothing else. I think memory has been exercised enough during install and
during first tests (running Mozilla and konqueror at the same time under Gnome ;-). It would
really be a very bad coincidence to always hit that bad memory block on kernel compile.
Which leaves libc: but why doesn't anything else that uses libc segfault then?