[OE-core] qemu rebuild contamination

[Khem Raj]

On Sun, Oct 27, 2019 at 7:19 PM Richard Purdie <
richard.purdie at linuxfoundation.org> wrote:

> On Sun, 2019-10-27 at 07:56 -0700, akuster808 wrote:
> >
> > 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.
>
> I'm travelling so a little out of sync, I see the email now. I think I
> managed to hit the rebuild issue when I tried to debug it which is why
> it seemed related to me.
>
> For the libdrm issue in warrior, we could:
>
> a) Break policy and upgrade libdrm
> b) Just upgrade libdrm-native and nativesdk
> c) Mark f30 as broken in warrior for qemugl and not expected to work.
>
> Any thougts?


I support c ad well but I think there is some hope to identify a fix that
can be backported

>
>
> I'm tempted by c).
>
> Cheers,
>
> Richard
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20191027/5d8d59e3/attachment.html>