[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8499950a0711040755g4360fe1ew25086642de160b19@mail.gmail.com>
Date: Sun, 4 Nov 2007 16:55:30 +0100
From: "Oleg Verych" <olecom@...il.com>
To: "Adrian Bunk" <bunk@...nel.org>
Cc: "David Miller" <davem@...emloft.net>, mingo@...e.hu,
sam@...nborg.org, thomas@...hlinux.org, tglx@...utronix.de,
linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
akpm@...ux-foundation.org
Subject: Re: 2.6.24-rc1-82798a1 compile failure (x86_64)
= 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists