semantic: 0.713
user-level: 0.659
ppc: 0.604
boot: 0.580
virtual: 0.556
device: 0.550
PID: 0.518
network: 0.509
architecture: 0.442
i386: 0.413
debug: 0.411
graphic: 0.401
x86: 0.395
hypervisor: 0.393
register: 0.385
kernel: 0.379
socket: 0.300
KVM: 0.286
mistranslation: 0.278
peripherals: 0.277
performance: 0.246
vnc: 0.233
files: 0.215
risc-v: 0.204
VMM: 0.199
arm: 0.182
TCG: 0.174
permissions: 0.152
assembly: 0.149

Build fails on optionrom

Git pseudo-bisected (focused on optionrom commits) it to this commit.

commit cdbd727c20ad7aac7797dc8c95e485e1a4c6901b
Author: Richard Henderson <email address hidden>
Date:   Thu Jul 7 21:49:36 2016 -0700

    build: Use $(AS) for optionrom explicitly


Build output (non-verbose):

  AS    optionrom/linuxboot.o
cpp: fatal error: '-c' is not a valid option to the preprocessor
compilation terminated.
cpp: fatal error: '-c' is not a valid option to the preprocessor
compilation terminated.
  CC    optionrom/linuxboot_dma.o
  CC    /home/bkamath/dev/workspace/block-2/mothra/output/sp0/targetqga/main.o
  AS    optionrom/kvmvapic.o
cpp: fatal error: '-c' is not a valid option to the preprocessor
compilation terminated.

Steps to reproduce:
Using buildroot and overriding qemu version to 2.7.0
Fedora 24, cpp (GCC) 6.2.1 20160916 (Red Hat 6.2.1-2)

I tried first just building without the -c option but it hangs indefinitely. Reverting the above listed commit fixes the problem on my platform. I didn't dive much further into this, because this seems like a regression.

I am seeing the same problem.  Cross compiling QEMU 2.7 using buildroot get fatal error -c is not a valid option.  As Benjamin states removing the -c flag from Makefile gets through the compile, but when booting a virtual image of Ubuntu 16.04 the network does not come up (console is live and you can login through the console, but the only network interface is loopback) I have not diagnosed further.

I was not able to simply back out the optionrom commit Benjamin cites... caused problems elsewhere, perhaps because I was not doing it right.  Reverting to QEMU 2.6.2 does work.

David

Looking through old bug tickets... can you still reproduce this issue with the latest version of QEMU? Or could we close this ticket nowadays?

[Expired for QEMU because there has been no activity for 60 days.]