I noticed this when trying to build qemu on my headless server with USE="-sdl" and QEMU_USER_TARGETS="" in effect. The build process died because it could not find any SDL headers. From the ebuild: einfo "Disabling usermode emulation (no usermode targets specified)" conf_opts="--disable-linux-user" It's paying no heed to conf_opts as it has been defined up to that point, therefore the options I need are discarded - in this case, "--disable-gfx-check --disable-sdl". The 0.10.4 and 0.10.3 ebuilds are also affected.
Now qemu-0.10.6 has been committed which suffers from the same problem. Is there really any reason for this immensely trivial fix not to be applied in a timely fashion?
Bump. Here's another example of the impact of this. Let's assume that libsdl and ncurses are present on the system. Let's see what happens with a minimal build of qemu - I'll just select at least one valid softmmu target and leave the usermode targets out so as to trigger the bug: 1) USE="-* qemu_softmmu_targets_i386" emerge -pv qemu [ebuild N ] app-emulation/qemu-0.11.1 USE="-alsa -bluetooth -esd -gnutls -kqemu -kvm -ncurses -pulseaudio -sasl -sdl -vde" QEMU_SOFTMMU_TARGETS="i386 -arm -cris -m68k -mips -mips64 -mips64el -mipsel -ppc -ppc64 -ppcemb -sh4 -sh4eb -sparc -x86_64" QEMU_USER_TARGETS="-alpha -arm -armeb -cris -i386 -m68k -mips -mips64 -mips64el -mipsel -ppc -ppc64 -ppc64abi32 -sh4 -sh4eb -sparc -sparc32plus -sparc64 -x86_64" 0 kB OK, now let's install it for real: 2) USE="-* qemu_softmmu_targets_i386" emerge qemu 3) ldd /usr/bin/qemu | awk '{ print $1 }' linux-vdso.so.1 libm.so.6 libpthread.so.0 librt.so.1 libz.so.1 libgnutls.so.26 libutil.so.1 libSDL-1.2.so.0 libncurses.so.5 libcurl.so.4 libssl.so.0.9.8 libcrypto.so.0.9.8 libdl.so.2 libc.so.6 /lib64/ld-linux-x86-64.so.2 libtasn1.so.3 libgcrypt.so.11 libgpg-error.so.0 Er, so why is it linking to libsdl and ncurses, to name but two examples? Well, here's what happened here when it ran ./configure: ./configure --disable-linux-user --prefix=/usr '--audio-drv-list=sdl oss' --cc=x86_64-pc-linux-gnu-gcc --host-cc=x86_64-pc-linux-gnu-gcc '--target-list= i386-softmmu ppc-softmmu' But it should have run: ./configure --disable-darwin-user --disable-bsd-user --disable-strip --disable-vnc-tls --disable-curses --disable-vnc-sasl --disable-sdl --disable-vde --disable-bluez --disable-kqemu --disable-kvm --disable-linux-user --prefix=/usr '--audio-drv-list=sdl oss' --cc=x86_64-pc-linux-gnu-gcc --host-cc=x86_64-pc-linux-gnu-gcc '--target-list= i386-softmmu ppc-softmmu' And there are other libraries that are being automagically linked in, which the ebuild isn't even exerting any control over. For instance, it linked to curl simply because it was present on the system. Even if the bug I'm complaining about was fixed, it would still continue to do that because the ebuild is missing: use curl || conf_opts="$conf_opts --disable-curl" ... not to mention a USE-based dependency on curl. There may be others too but I didn't bother checking. All qemu ebuilds continue to be affected. Adding QA as it seems evident that nothing is going to be done about this otherwise.
Fixed as Luca is on vacation.
I should add that the build failure no longer occurs under the original circumstances described in the first comment in the latest version (qemu-0.11.1) but that is purely through 'fortune' rather than intervention; I can only assume that the qemu build system no longer considers the absence of a library that is not explicitly disabled as a critical error. The bug still stands and the impact of it - and the other issues with the ebuild - should be clear. EDIT: Noticed the response after typing the above. Diego, thanks for looking into it so quickly. I haven't yet seen the change but I presume that you've just attended to line #111 of the ebuild. However, there are other QA issues as mentioned just prior. That is, the ./configure options need to be reviewed and taken into consideration. I presume that I should file a separate bug to that end?
