gcc 2.96, included with RedHat 7, will not compile a kernel. cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -c -o sym53c8xx.o sym53c8xx.c sym53c8xx.c:11548:16: warning: junk on line after #undef sym53c8xx.c:11549:16: warning: junk on line after #undef sym53c8xx.c:11550:16: warning: junk on line after #undef sym53c8xx.c:11551:16: warning: junk on line after #undef cc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -pipe -fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2 -DCPU=686 -DEXPORT_SYMTAB -c cdrom.c cdrom.c:395:73: warning: pasting would not give a valid preprocessing token cdrom.c:426:75: warning: pasting would not give a valid preprocessing token cdrom.c:484:88: warning: pasting would not give a valid preprocessing token cdrom.c:502:57: warning: pasting would not give a valid preprocessing token cdrom.c:554:67: warning: pasting would not give a valid preprocessing token cdrom.c:567:64: warning: pasting would not give a valid preprocessing token cdrom.c:609:57: warning: pasting would not give a valid preprocessing token cdrom.c:668:83: warning: pasting would not give a valid preprocessing token cdrom.c:896:61: warning: pasting would not give a valid preprocessing token cdrom.c:900:40: warning: pasting would not give a valid preprocessing token cdrom.c:1132:76: warning: pasting would not give a valid preprocessing token cdrom.c:1247:84: warning: pasting would not give a valid preprocessing token cdrom.c:1281:57: warning: pasting would not give a valid preprocessing token cdrom.c:1311:48: warning: pasting would not give a valid preprocessing token cdrom.c:1602:74: warning: pasting would not give a valid preprocessing token cdrom.c:1615:76: warning: pasting would not give a valid preprocessing token cc -D__KERNEL__ -I/usr/src/linux/include -D__ASSEMBLY__ -traditional -c checksum.S -o checksum.o checksum.S:231: badly punctuated parameter list in #define checksum.S:237: badly punctuated parameter list in #define make[2]: *** [checksum.o] Error 1 make[2]: Leaving directory `/usr/src/linux-2.2.17/arch/i386/lib' make[1]: *** [first_rule] Error 2 make[1]: Leaving directory `/usr/src/linux-2.2.17/arch/i386/lib' make: *** [_dir_arch/i386/lib] Error 2
Use "kgcc" (located on CD1) to compile the kernel. This is not a bug.
Okay, so how does one do that? And, for modules compiled outside the kernel tree (universal tun driver, for instance), how does one do that? On a somewhat separate note, why goes RH7 ship with a broken compiler by default, and a working compiler that must be installed separately?
export CC=kgcc make ... It's not the compiler that is broken, it's mostly the the _kernel_ that is broken and relies on some hacks which work only with this older compiler. See the linux-kernel mailing list archives for frequent discussion of this topic. Get your facts straight before accusing someone :->
In fact, for 2.2 kernels use make CC='kgcc -D__KERNEL__ -I$(HPATH)', for 2.4 kernels you should be able to use normal gcc, or if you want to be safe, make CC=kgcc. Note that later 2.2.18pre kernels already use kgcc automatically if it is available in /usr/bin. The default compiler is not as broken as you think, from your report above only some of the pasting would not give a valid preprocessing token warnings (note, not errors) are inappropriate (but it has been fixed since then and errata will be made within at most 2 weeks), some are appropriate though (inappropriate only for GNU ,## extensions). The #undef message is really a warning about bug in the kernel, there should be no junk after it, and checksum.S fails because one should not use GNU restarts extensions in K&R preprocessor simply because those extensions don't exist in K&R, ie. either compile checksum.S without -traditional (that's what 2.4 kernels do e.g.), or avoid using restarts extensions in it. Anyway, 2.2. kernels have not been sufficiently tested if they work if compiled with gcc 2.96, so they'd probably work, but you'd have to roll your own...