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

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Sat, 2019-02-23 at 13:25 +0000, Richard Purdie wrote:
> On Sat, 2019-02-23 at 13:51 +0100, Alexander Kanavin 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...

Cheers,

Richard