[OE-core] qemu rebuild contamination

akuster808 akuster808 at gmail.com
Sun Oct 27 14:56:37 UTC 2019



On 10/27/19 2:57 AM, Richard Purdie wrote:
> 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?
You mean the virgl failure? I did set the native packconfig to make the
selftest and that had no affect. In facted, Zeus has the same mismatch.
Alex's patches I believe align them to match.

The virgl failure is fixed using an updated version of libdrm. I thought
I sent an email about that.

- armin
>
> Cheers,
>
> Richard
>



More information about the Openembedded-core mailing list