All of lore.kernel.org
 help / color / mirror / Atom feed
From: Giacomo Catenazzi <cate@cateee.net>
To: Adrian Bunk <bunk@kernel.org>
Cc: David Miller <davem@davemloft.net>,
	mingo@elte.hu, sam@ravnborg.org, thomas@archlinux.org,
	tglx@linutronix.de, linux-kernel@vger.kernel.org,
	linux-kbuild@vger.kernel.org, akpm@linux-foundation.org
Subject: Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
Date: Sun, 04 Nov 2007 19:33:41 +0100	[thread overview]
Message-ID: <472E1085.8040801@cateee.net> (raw)
In-Reply-To: <20071104163439.GM12045@stusta.de>

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

  reply	other threads:[~2007-11-04 18:34 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-10-29 21:46 2.6.24-rc1-82798a1 compile failure (x86_64) Thomas Bächler
2007-10-29 22:12 ` Thomas Gleixner
     [not found]   ` <47266BF6.6070206@archlinux.org>
     [not found]     ` <alpine.LFD.0.9999.0710300033470.3186@localhost.localdomain>
2007-10-30  9:10       ` Thomas Bächler
2007-11-03 10:04         ` Thomas Bächler
2007-11-03 12:11           ` Sam Ravnborg
2007-11-04  2:02             ` Adrian Bunk
2007-11-04 10:04               ` Ingo Molnar
2007-11-04 10:19                 ` Sam Ravnborg
2007-11-04 10:31                 ` David Miller
2007-11-04 11:16                   ` Sam Ravnborg
2007-11-04 12:27                     ` Thomas Bächler
2007-11-04 15:29                   ` Adrian Bunk
2007-11-04 15:55                     ` Oleg Verych
2007-11-04 16:19                     ` Giacomo Catenazzi
2007-11-04 16:34                       ` Adrian Bunk
2007-11-04 18:33                         ` Giacomo Catenazzi [this message]
2007-11-05  4:03                         ` David Miller
2007-11-04 18:10                     ` Sam Ravnborg
2007-11-05  4:01                     ` David Miller
2007-11-06 17:32               ` Arjan van de Ven
2007-11-07  0:12                 ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=472E1085.8040801@cateee.net \
    --to=cate@cateee.net \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@kernel.org \
    --cc=davem@davemloft.net \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sam@ravnborg.org \
    --cc=tglx@linutronix.de \
    --cc=thomas@archlinux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.