Re: Kernel compilation failure
On Tue, Sep 27, 2005 at 04:58:17PM +0200, Gilles wrote:
> Following your advice, this is now the command I entered:
>
> MAKEFLAGS='V=1' make-kpkg --append-to-version +g2 kernel_image modules_image
>
> And here are the messages:
>
> [...]
> /usr/bin/make -f scripts/Makefile.build obj=drivers/base
> /usr/bin/make -f scripts/Makefile.build obj=drivers/base/power
> /usr/bin/make -f scripts/Makefile.build obj=drivers/block
> gcc -Wp,-MD,drivers/block/.rd.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.0.2/include -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer -march=k8 -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -DKBUILD_BASENAME=rd -DKBUILD_MODNAME=rd -c -o drivers/block/.tmp_rd.o drivers/block/rd.c
> /bin/sh: line 1: 2419 Segmentation fault gcc -Wp,-MD,drivers/block/.rd.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.0.2/include -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer -march=k8 -mno-red-zone -mcmodel=kernel -pipe -fno-reorder-blocks -Wno-sign-compare -fno-asynchronous-unwind-tables -funit-at-a-time -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -DKBUILD_BASENAME=rd -DKBUILD_MODNAME=rd -c -o drivers/block/.tmp_rd.o drivers/block/rd.c
> make[3]: *** [drivers/block/rd.o] Error 139
> make[2]: *** [drivers/block] Error 2
> make[1]: *** [drivers] Error 2
> make[1]: Leaving directory `/home/eran/system/kernel/source/linux-source-2.6.12'
> make: *** [stamp-build] Error 2
That '2419 Segmentation fault gcc ....' looks bad. gcc only
segfaults on compiler bugs or hardware errors in my experience. Of
course being gcc 4.0.x compiler bugs are entirely possible.
On the other hand the fact it is _not_ happening the same place each
time rather makes the hardware error much more likely.
If you can do make clean and then build it and have it fail the same
place 3 or 4 times in a row, then submit a bugreport on gcc-4.0.
If it doesn't fail the same place each of those times, start swapping ram,
cpu, etc, until you find the faulty hardware.
It seems rather unlikely that a bug in gcc-4.0 could cause random place
segfaults although it's not 100% imposible, just very very unlikely.
Len Sorensen
Reply to: