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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
