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

Oleg Verych
2007-11-04T15:55:41Z

= 11/4/07 =

> > > > 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.
[]
> > ...
> > > At minimum the extra CFLAGS needs to be put into the .config - but
> > > that's not a too nice solution either.

A y/n config option to pull flags from the env?

> > > 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.
> >
> > I totally disagree.

I do too. Every ordinary (like shell, i.e. which is not setting own env
program) exec*() will copy that mostly useless var for every subshell,
`cat`, `cp`, `mv`...

[]
> > 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.
[]
--
-o--=O`C
#oo'L O
<___=E M