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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Adrian Bunk wrote:
On Sun, Nov 04, 2007 at 05:19:45PM +0100, Giacomo Catenazzi wrote:
Adrian Bunk wrote:
On Sun, Nov 04, 2007 at 02:31:33AM -0800, David Miller wrote:
From: Ingo Molnar <[email protected]>
Date: Sun, 4 Nov 2007 11:04:29 +0100

* Adrian Bunk <[email protected]> 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.
????

Are you sure???

From http://www.gnu.org/software/make/manual/make.html#Environment

: Variables in make can come from the environment in which make
: is run. Every environment variable that make sees when it starts
: up is transformed into a make variable with the same name and
: value.

and most important:

: Thus, by setting the variable CFLAGS in your environment, you
: can cause all C compilations in most makefiles to use the
: compiler switches you prefer. This is safe for variables with
: standard or conventional meanings because you know that no
: makefile will use them for other things. (Note this is not
: totally reliable; some makefiles set CFLAGS explicitly and
: therefore are not affected by the value in the environment.)


Thanks for the correction, I had forgotten about the case where a Makefile does not set CFLAGS at all.

But the main point that stuff like e.g. -I/usr/local/dist/include that might in some environments be correct for all and required for most userspace software should not leak into the kernel still stands.

Yes, you are right.
Kernel uses the gcc in "freestanding" mode, so I think we should
eventually share the compiler options and environment only with
other freestanding programs (aka: none).

ciao
	cate
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux