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

[Oleg Verych]

= 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/