Hi all, > 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: > > > > [EMAIL PROTECTED]:/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[1]: 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[1]: *** [fastdep] Segmentation fault > > make[1]: 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? Cheers Michel (clueless) -- .sig asleep
