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

[Sam Ravnborg <sam@ravnborg.org>]

> > If people set something like CFLAGS in their environment, they must
> > understand what that means, and it means that universally it will
> > influence your Makefile based builds.  Yes, this means all of them and
> > even potentially the kernel build.
> > 
> > I definitely think the new kbuild CFLAGS behavior is just fine.  I
> > would never ever set CFLAGS globally in my environment and expect sane
> > things to happen.
> > 
> > If people do stupid things in their environment without being willing
> > to accept all of the consequences, that isn't a reason to not provide
> > this feature in kbuild.
> > 
> > Do you even understand that taking this out of kbuild will just push
> > the problem one level of indirection away?  Say this stupid CFLAGS
> > setting creaps into someone's gcc bootstrap, and that gcc miscompiles
> > the kernel.  You will have fun debugging that too, but I'm sad to say
> > you won't be able to pass the blame to kbuild on that one 8-/
> > 
> > It's just more proof that setting CFLAGS globally in your environment
> > is just plain stupid and asking for trouble.
> > 
> > Don't do it.
> 
> I'm not seeing what's stupid about this.
> 
> I had for years CFLAGS="-O2 -mcpu=v8" set in the environment on a
> machine where I compiled virtually all software (including gcc), and 
> different similar settings on other machines, without running into any 
> problems.
> 
> I also doubt it's wanted that the kernel picks up the -I/-L/-R flags
> I have set in some environments where many libraries are installed in 
> non-standard places.

I fully agree with David that people should realize that setting some
well-known variable can affect quite a lot.
But I also see that people use this for pure userspace issues.
So I will shortly submit a patch to Linus that uses KCFLAGS &
friends and warn if a value is picked up.

	Sam