[OE-core] qemu rebuild contamination

[Richard Purdie]

I've been trying to figure out why we get a weird build failure with
hash equivalence enabled. Armin has also been searching for an odd
issue with warrior and the qemu tests. I may have a lead.

If you build a standard qemu:

"bitbake qemu-system-native"

and save off the resulting qemu-system-XXX binaries, then add:

PACKAGECONFIG_append_pn-qemu-system-native = " gtk+"
PACKAGECONFIG_append_pn-qemu-system-native = " virglrenderer"
PACKAGECONFIG_append_pn-qemu-system-native = " glx"

to local.conf, then:

"bitbake qemu-system-native"

it rebuilds as expected, save off the qemu-system-XXX binaries,

then remove the local.conf entries and:

"bitbake qemu-system-native -c configure -f"
"bitbake qemu-system-native"

then save off the resulting qemu-system-XXX binaries, you'll find that
whilst these first and last sets should match, they don't. Its obvious
with "ldd qemu-system-x86_64" that the linked libraries persist from
the second to third set when they should not.

The reason is that when configuration changes, autotools.bbclass will
wipe out ${B} however qemu doesn't use the autotools class and hence B
is not cleaned for changes in configuration.

We could abstract the pieces of autotools.bbclass which do this into a
separate class, or, easier, have qemu's do_configure wipe ${B}.

Armin: This may be the issue you're searching for with warrior?

Cheers,

Richard