It seems that a test for the frame pointer gcc bug was incorrectly added
to the build process, rejecting all 2.96 compilers (which generate better
code than 3.2) instead of just the broken ones.
gcc -Wp,-MD,init/.main.o.d -D__KERNEL__ -Iinclude -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
-pipe -mpreferred-stack-boundary=2 -march=i686
-Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include
-DKBUILD_BASENAME=main -DKBUILD_MODNAME=main -c -o init/main.o init/main.c
init/main.c:49:2: #error This compiler cannot compile correctly with frame
pointers enabled
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
oddball:davidsen> gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs
gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)
On Fri, Mar 21, 2003 at 02:14:16PM -0500, Bill Davidsen wrote:
> It seems that a test for the frame pointer gcc bug was incorrectly added
> to the build process, rejecting all 2.96 compilers (which generate better
> code than 3.2) instead of just the broken ones.
[snip]
AFAICT Linus did this intentionally:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.1/1031.html
"Yeah, it will get some fixed compilers too, but that's just not worth
worrying about - people will just have to turn off CONFIG_FRAME_POINTER
and be happy."
-Barry K. Nathan <[email protected]>
On Fri, 21 Mar 2003, Barry K. Nathan wrote:
> On Fri, Mar 21, 2003 at 02:14:16PM -0500, Bill Davidsen wrote:
> > It seems that a test for the frame pointer gcc bug was incorrectly added
> > to the build process, rejecting all 2.96 compilers (which generate better
> > code than 3.2) instead of just the broken ones.
> [snip]
>
> AFAICT Linus did this intentionally:
>
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0303.1/1031.html
>
> "Yeah, it will get some fixed compilers too, but that's just not worth
> worrying about - people will just have to turn off CONFIG_FRAME_POINTER
> and be happy."
>
> -Barry K. Nathan <[email protected]>
So the choice is to use the 3.x compiler which has issues as well as
generating slow code, or to not be able to generate a decent error report
if something doesn't work right, rip the half-assed check out, or just use
2.4 kernels.
The problem is that it gets ALL fixed compilers in the 2.96 family, only a
few are broken, and it seems safe to assume that people who are building
test kernels probably have upgraded their compiler.
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Sat, Mar 22, 2003 at 07:30:54AM -0500, Bill Davidsen wrote:
> So the choice is to use the 3.x compiler which has issues as well as
> generating slow code, or to not be able to generate a decent error report
> if something doesn't work right, rip the half-assed check out, or just use
> 2.4 kernels.
There's another option: gcc 2.95.[34].
-Barry K. Nathan <[email protected]>