<div><br></div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Oct 27, 2019 at 7:19 PM Richard Purdie <<a href="mailto:richard.purdie@linuxfoundation.org">richard.purdie@linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 2019-10-27 at 07:56 -0700, akuster808 wrote:<br>
> <br>
> On 10/27/19 2:57 AM, Richard Purdie wrote:<br>
> > I've been trying to figure out why we get a weird build failure<br>
> > with<br>
> > hash equivalence enabled. Armin has also been searching for an odd<br>
> > issue with warrior and the qemu tests. I may have a lead.<br>
> > <br>
> > If you build a standard qemu:<br>
> > <br>
> > "bitbake qemu-system-native"<br>
> > <br>
> > and save off the resulting qemu-system-XXX binaries, then add:<br>
> > <br>
> > PACKAGECONFIG_append_pn-qemu-system-native = " gtk+"<br>
> > PACKAGECONFIG_append_pn-qemu-system-native = " virglrenderer"<br>
> > PACKAGECONFIG_append_pn-qemu-system-native = " glx"<br>
> > <br>
> > to local.conf, then:<br>
> > <br>
> > "bitbake qemu-system-native"<br>
> > <br>
> > it rebuilds as expected, save off the qemu-system-XXX binaries,<br>
> > <br>
> > then remove the local.conf entries and:<br>
> > <br>
> > "bitbake qemu-system-native -c configure -f"<br>
> > "bitbake qemu-system-native"<br>
> > <br>
> > then save off the resulting qemu-system-XXX binaries, you'll find<br>
> > that<br>
> > whilst these first and last sets should match, they don't. Its<br>
> > obvious<br>
> > with "ldd qemu-system-x86_64" that the linked libraries persist<br>
> > from<br>
> > the second to third set when they should not.<br>
> > <br>
> > The reason is that when configuration changes, autotools.bbclass<br>
> > will<br>
> > wipe out ${B} however qemu doesn't use the autotools class and<br>
> > hence B<br>
> > is not cleaned for changes in configuration.<br>
> > <br>
> > We could abstract the pieces of autotools.bbclass which do this<br>
> > into a<br>
> > separate class, or, easier, have qemu's do_configure wipe ${B}.<br>
> > <br>
> > Armin: This may be the issue you're searching for with warrior?<br>
> You mean the virgl failure? I did set the native packconfig to make<br>
> the<br>
> selftest and that had no affect. In facted, Zeus has the same<br>
> mismatch.<br>
> Alex's patches I believe align them to match.<br>
> <br>
> The virgl failure is fixed using an updated version of libdrm. I<br>
> thought I sent an email about that.<br>
<br>
I'm travelling so a little out of sync, I see the email now. I think I<br>
managed to hit the rebuild issue when I tried to debug it which is why<br>
it seemed related to me.<br>
<br>
For the libdrm issue in warrior, we could:<br>
<br>
a) Break policy and upgrade libdrm<br>
b) Just upgrade libdrm-native and nativesdk<br>
c) Mark f30 as broken in warrior for qemugl and not expected to work.<br>
<br>
Any thougts?</blockquote><div dir="auto"><br></div><div dir="auto">I support c ad well but I think there is some hope to identify a fix that can be backported </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
I'm tempted by c).<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</blockquote></div></div>