lkml.org 
[lkml]   [2007]   [Nov]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.24-rc1-82798a1 compile failure (x86_64)
    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
    -
    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/

    \
     
     \ /
      Last update: 2007-11-04 19:37    [W:0.030 / U:0.616 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site