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

Sam Ravnborg
2007-11-04T18:08:35Z

> > 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