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


Reply via email to