Re: 2.6.24-rc1-82798a1 compile failure (x86_64)

[Sam Ravnborg <sam@ravnborg.org>]

On Sun, Nov 04, 2007 at 11:04:29AM +0100, Ingo Molnar wrote:
> 
> * Adrian Bunk <bunk@kernel.org> wrote:
> 
> > On Sat, Nov 03, 2007 at 01:11:49PM +0100, Sam Ravnborg wrote:
> > > On Sat, Nov 03, 2007 at 11:04:36AM +0100, Thomas Bächler wrote:
> > > > Thomas Bächler schrieb:
> > > > > 
> > > > > I just remembered, a friend of mine got it to compile with the exact
> > > > > same toolchain, but with a different configuration (which I don't have).
> > > > > He used a snapshot tarball from yesterday though, not the git tree.
> > > > > 
> > > > 
> > > > I found the problem and eliminated it. While this is my own fault, it is
> > > > still a bug in either the kernel or the build system: I had CFLAGS set
> > > > to "-Wall -O3 -march=native -pipe". I always thought the kernel would
> > > > ignore those and set its own CFLAGS, but I was wrong. Either the -O3 or
> > > > the -march=native break the build process on gcc 4.2.2.
> > > > 
> > > The kernel will now honour the users CFLAGS setting as you just discovered.
> > > The flags will be appended to the flags specified by the kernel.
> > >...
> > 
> > I think this should be changed:
> > 
> > I also have CFLAGS set on some computers in my environments since for 
> > packages using GNU autoconf that's the correct way to set the compiler 
> > flags.
> > 
> > The kernel already sets all flags correctly, and a user wanting to 
> > change the flags for the kernel is an exception with very special 
> > needs (I'd even claim so special that he could simply edit the 
> > Makefile...).
> > 
> > Using the *FLAGS automatically in the kernel doesn't sound right, can 
> > we prefix all environment variables the kernel honours with KERNEL_ ?
> 
> this _must_ be changed before v2.6.24 is released. Thomas Bächler, 
> Thomas Gleixner and me already wasted hours on this problem, and these 
> kinds of issues will reoccur again and again - in perhaps even more 
> spurious ways.
> 
> Picking up randon environment details during build reduces 
> reproducability (i couldnt reproduce the problem using the exact same 
> toolchain) and might break various existing setups and distro builds as 
> well.
> 
> At minimum the extra CFLAGS needs to be put into the .config - but 
> that's not a too nice solution either. How about just adding an 
> extra-CFLAGS option to .config and perhaps a 'make configpickupCFLAGS' 
> pass for anyone who wants to propagate the environment CFLAGS into the 
> kernel build.

The simpler solutions are to
a) only pick up the values if specified on the make command line as in:
   make CFLAGS=-O3
   [CFLAGS set in the environment would be ignored]
b) do not pick up these variables at all
c) Pick up variables with a unique name

I just did c) but all three options are simple.
Comments?

	Sam

diff --git a/Makefile b/Makefile
index 188c3b6..67c0639 100644
--- a/Makefile
+++ b/Makefile
@@ -527,10 +527,11 @@ KBUILD_CFLAGS += $(call cc-option,-Wdeclaration-after-statement,)
 # disable pointer signed / unsigned warnings in gcc 4.0
 KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
 
-# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
-KBUILD_CPPFLAGS += $(CPPFLAGS)
-KBUILD_AFLAGS   += $(AFLAGS)
-KBUILD_CFLAGS   += $(CFLAGS)
+# Add user supplied KCPPFLAGS, KAFLAGS and KCFLAGS as the last assignments
+# (The K prefix is added so we do not pick up often-used variables)
+KBUILD_CPPFLAGS += $(KCPPFLAGS)
+KBUILD_AFLAGS   += $(KAFLAGS)
+KBUILD_CFLAGS   += $(KCFLAGS)
 
 # Use --build-id when available.
 LDFLAGS_BUILD_ID = $(patsubst -Wl$(comma)%,%,\
> 
> 	Ingo