On 10/27/19 12:26 PM, Khem Raj wrote: > > > On Sun, Oct 27, 2019 at 7:19 PM Richard Purdie > <richard.pur...@linuxfoundation.org > <mailto:richard.pur...@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. > errrr, Looking at the test report for 2.7.1, this failed back then too so saying it does not work is fine.
https://autobuilder.yocto.io/pub/releases/yocto-2.7.1.rc1/testresults/oe-selftest-fedora/testresults.json -armin > > > 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@lists.openembedded.org > <mailto:Openembedded-core@lists.openembedded.org> > http://lists.openembedded.org/mailman/listinfo/openembedded-core >
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
