[OE-core] [PATCH 3/4] gdk-pixbuf: convert from autotools to meson

Alexander Kanavin alex.kanavin at gmail.com
Sat Feb 23 13:43:31 UTC 2019


On Sat, 23 Feb 2019 at 14:36, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> > > I'm at the same time staring at this bit in pixbufcache.bbclass:
> > >
> > > gdkpixbuf_complete() {
> > > GDK_PIXBUF_FATAL_LOADER=1
> > > ${STAGING_LIBDIR_NATIVE}/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders
> > > --update-cache || exit 1
> > > }
> > >
> > > DEPENDS_append_class-native = " gdk-pixbuf-native"
> > > SYSROOT_PREPROCESS_FUNCS_append_class-native = "
> > > pixbufcache_sstate_postinst"
> > >
> > > # See base.bbclass for the other half of this
> > > pixbufcache_sstate_postinst() {
> > >         mkdir -p ${SYSROOT_DESTDIR}${bindir}
> > >         dest=${SYSROOT_DESTDIR}${bindir}/postinst-${PN}
> > >         echo '#!/bin/sh' > $dest
> > >         echo "${gdkpixbuf_complete}" >> $dest
> > >         chmod 0755 $dest
> > > }
> > >
> > > It's all written for -native, yet the script that fails, resides in
> > > tmp/sysroots/qemux86-64/usr/bin/postinst-gdk-pixbuf-native (e.g.
> > > the
> > > target sysroot which is racing with the native one). Why is it even
> > > there?
> > > I haven't written this code :) and haven't really seen it before,
> > > but
> > > this might be a lead.
> >
> > I'm sure I've worked on the above before, my memory of why we need it
> > is fuzzy. I do now have a reproducer though:
> >
> > bitbake gdk-pixbuf gdk-pixbuf-native
> > then
> > bitbake build-sysroots -c build_target_sysroot
> >
> > If you bake build_native_sysroot first, the problem goes away.
>
> I think the problem is in staging_populate_sysroot_dir(). It's
> confusing target and native package_archs since in the case we see this
> its x86_64 where the target and build archs match.
>
> Not entirely sure how we'll fix this but that is where I think the
> problem is.
>
> Not sure why we're suddenly seeing it now and whether the patches
> somehow trigger it or not...

The reproducer does fail on master too, so the patches may only have
shifted the timings such that the race outcome is sometimes the
failing one.

Alex


More information about the Openembedded-core mailing list