I'm scratching my head on this one, but here's my problem:
% ./configure --target-list=x86_64-softmmu
--kerneldir=/home/hollisb/work/linux-2.6.hg
% make V=1
[...]
gcc -I/home/hollisb/work/qemu.git/slirp -Werror -m32
-fstack-protector-all -Wold-style-definition -Wold-style-declaration -I.
-I/home/hollisb/work/qemu.git -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes
-Wredundant-decls -Wall -Wundef -Wendif-labels -Wwrite-strings
-Wmissing-prototypes -fno-strict-aliasing -DHAS_AUDIO
-DHAS_AUDIO_CHOICE -I/home/hollisb/work/qemu.git/fpu
-I/home/hollisb/work/qemu.git/tcg
-I/home/hollisb/work/qemu.git/tcg/i386 -DTARGET_PHYS_ADDR_BITS=64 -I..
-I/home/hollisb/work/qemu.git/target-i386 -DNEED_CPU_H
-I/home/hollisb/work/linux-2.6.hg/include
-I/home/hollisb/work/linux-2.6.hg/arch/x86/include -MMD -MP -MT
vhost_net.o -MF ./vhost_net.d -O2 -g -c -o vhost_net.o
/home/hollisb/work/qemu.git/hw/vhost_net.c
In file included from
/home/hollisb/work/linux-2.6.hg/arch/x86/include/asm/sigcontext.h:5,
from /usr/include/bits/sigcontext.h:28,
from /usr/include/signal.h:339,
from /home/hollisb/work/qemu.git/cpu-defs.h:29,
from /home/hollisb/work/qemu.git/target-i386/cpu.h:46,
from /home/hollisb/work/qemu.git/qemu-common.h:100,
from /home/hollisb/work/qemu.git/net.h:5,
from /home/hollisb/work/qemu.git/hw/vhost_net.c:13:
/home/hollisb/work/linux-2.6.hg/include/linux/types.h:13:2: error:
#warning "Attempt to use kernel headers from user space, see
http://kernelnewbies.org/KernelHeaders"
The problem seems to be that jump from /usr/include/bits/sigcontext.h to
asm/sigcontext.h inside <kerneldir> rather than inside /usr/include. It
seems like adding -Ikerneldir/arch/foo/include will always be a problem,
since it will always be used to satisfy "#include <asm/bar.h>". Only
files built with KVM_CFLAGS would be affected, and I guess vhost_net.c
accidentally gets into a broken include path where the other KVM_CFLAGS
files doesn't.
I'm wondering why this isn't causing more problems for more people. My
host is Fedora 12, FWIW, but this doesn't seem like it could at all be
related to toolchain version, for example.
--
Hollis Blanchard
Mentor Graphics, Embedded Systems Division