Messages in this thread | | | Date | Wed, 7 Nov 2007 01:12:00 +0100 | From | Adrian Bunk <> | Subject | Re: 2.6.24-rc1-82798a1 compile failure (x86_64) |
| |
On Tue, Nov 06, 2007 at 09:32:23AM -0800, Arjan van de Ven wrote: > On Sun, 4 Nov 2007 03:02:17 +0100 > Adrian Bunk <bunk@kernel.org> wrote: > > > On Sat, Nov 03, 2007 at 01:11:49PM +0100, Sam Ravnborg wrote: > > > On Sat, Nov 03, 2007 at 11:04:36AM +0100, Thomas Bächler wrote: > > > > Thomas Bächler schrieb: > > > > > > > > > > I just remembered, a friend of mine got it to compile with the > > > > > exact same toolchain, but with a different configuration (which > > > > > I don't have). He used a snapshot tarball from yesterday > > > > > though, not the git tree. > > > > > > > > > > > > > I found the problem and eliminated it. While this is my own > > > > fault, it is still a bug in either the kernel or the build > > > > system: I had CFLAGS set to "-Wall -O3 -march=native -pipe". I > > > > always thought the kernel would ignore those and set its own > > > > CFLAGS, but I was wrong. Either the -O3 or the -march=native > > > > break the build process on gcc 4.2.2. > > > > > > > The kernel will now honour the users CFLAGS setting as you just > > > discovered. The flags will be appended to the flags specified by > > > the kernel. > > >... > > I think we can solve a ton of issues if we don't make the CFLAGS > *append* but just *prepend*. That way, if the KConfig overrides a > certain CFLAG, that sticks... since gcc picks the last one in case of > conflicting options. That gives us both the honoring of cflags, and the > principle of least surprise in that KConfig options are honored...
CFLAGS="-I/usr/include -I/usr/local/dist/include"
I think the solution with KCFLAGS that is in 2.6.24-rc2 is the best one.
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/
| |