Messages in this thread | | | Date | Sun, 4 Nov 2007 16:29:30 +0100 | From | Adrian Bunk <> | Subject | Re: 2.6.24-rc1-82798a1 compile failure (x86_64) |
| |
On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote: > From: Ingo Molnar <mingo@elte.hu> > Date: Sun, 4 Nov 2007 11:04:29 +0100 > > > > > * Adrian Bunk <bunk@kernel.org> wrote: > > > > > 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...). > ... > > 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. > > I totally disagree. > > People can't have it both ways. CFLAGS has global meaning in every > Makefile based build tree, it's not an "autoconf" thing. This is well > established practice, and I think it's a good thing the kernel does it > now too.
Makefiles do normally not pick such variables from the environment.
> 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.
Altogether: - normally, Makefiles don't pick environment variables - most open source software uses GNU autoconf - GNU autoconf does pick environment variables - GNU autoconf documents to set *FLAGS in the environment - the kernel has different needs regarding the *FLAGS than userspace - automatically using the *FLAGS people have set in their environment for userspace software in the kernel will cause problems - the kernel should have already picked the optimal *FLAGS for you, and wanting different flags in the kernel is something quite exotic
cu Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |