On 17.03.2017 14:22, Peter Maydell wrote: > On 17 March 2017 at 13:19, Thomas Huth <th...@redhat.com> wrote: >> On 17.03.2017 12:52, Peter Maydell wrote: >>> On 17 March 2017 at 11:49, Daniel P. Berrange <berra...@redhat.com> wrote: >>>> On Fri, Mar 17, 2017 at 11:08:22AM +0000, Peter Maydell wrote: >>>>> We plan to drop support in a future QEMU release for host OSes >>>>> and host architectures for which we have no test machine where >>>>> we can build and run tests. For the 2.9 release, make configure >>>>> print a warning if it is run on such a host, so that the user >>>>> has some warning of the plans and can volunteer to help us >>>>> maintain the port if they need it to continue to function. >> >> I like your patch! ... but instead of completely aborting with >> "Unsupported host OS" when an unexpected host operating system has been >> detected, I'd maybe only print a warning and continue the configure >> process - in case it is a POSIX-compatible system, there is at least a >> small chance that QEMU can be compiled there. > > That code path tries to enable all the Linux specific stuff > (including KVM and linux-user and so on) and puts linux-headers/ > on the include path. It seems very unlikely that it will actually > work even if in theory a generic-POSIX OS might be able to build > QEMU somehow.
Ah, sorry, you got me slightly wrong. I think it is a good idea that you replaced the "*)" with "Linux)" in your patch. I rather meant to simply do "echo" instead of "error_exit" in the new "*)" case. I now just tried to build QEMU with such a "fake" generic POSIX system (by hacking configure to not recognize "Linux"), and seems like QEMU properly compiles in that case - but linking fails because net/tap.c is missing a tap backend. So you're right, currently it is not possible to build QEMU on unknown host systems, i.e. the "error_exit" is indeed justified there (though I think it would be maybe be possible to also add stubs for missing tap functions to make it work). Thomas