[OE-core] [PATCH 2/2] librsvg: Add missing pixbufcache dependencies

[Kyle Russell]

Actually, we just hit another failure mode running with these two patches.
Again, we're currently running on the jethro branch.

g_module_open() failed for
/poky/build/tmp/sysroots/x86_64-linux/usr/lib/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so:
libjpeg.so.9: cannot open shared object file: No such file or directory

Looking at the build output itself, I was reminded of another signature of
this failure.  It seems like the do_populate_lice_setscene runs for the
package that should have provided libjpeg.so.9, but no
do_populate_sysroot_setscene.  I remember also seeing this on the other
failures I mentioned.

$ cat build-output.log | grep jpeg-native
NOTE: recipe jpeg-native-9a-r0: task do_populate_lic_setscene: Started
NOTE: recipe jpeg-native-9a-r0: task do_populate_lic_setscene: Succeeded

I can try to get the full cooker log from the build slave if you want.  Do
you mean the file from tmp/log/cooker/<machine>/?  If I can get it, how
would you prefer me send that to you?

On Thu, Oct 13, 2016 at 9:09 AM, Burton, Ross <ross.burton at intel.com> wrote:

>
> On 11 October 2016 at 17:44, Kyle Russell <bkylerussell at gmail.com> wrote:
>
>> I suspect this list may still not be entirely complete, because ldd shows
>> several dependencies for libpixbufloader-svg.so.  However, I'm not really
>> that familiar with all the dependencies going on here; we are definitely
>> seeing sporadic failures for various native libraries during the
>> pixbufcache postinst task though.  Best I could tell, it looked like the
>> PIXBUFCACHE_SYSROOT_DEPS functionality was accidentally removed from the
>> pixbufcache.bbclass a while back (hence, my first patch).  Adding that hunk
>> back in has seemed to help most of the failures, but we still see lingering
>> failures for pixman and libXdmcp on occasion.
>
>
> This bit of code is particularly tangled, so I'm hoping I can remember the
> details.  The AB just hit a related problem earlier in the week so I'm
> trying to remember how all this ties together.
>
> The SYSROOT_DEPS bit wasn't removed accidentally because the way the
> query-loaders script is executed has changed.  It used to be ran via
> SSTATEPOSTINSTFUNCS so would execute the moment that gdk-pixbuf-native or
> librsvg-native was unpacked.  As sstate installation is top-down instead of
> bottom-up this would generally mean that librsvg-native would be installed
> before even gdk-pixbuf-native was installed, and typically before stuff
> like libpng-native or the rest of the stack.
>
> This was changed so that the SSTATEPOSTINSTFUNC simply writes a
> sstate-completion script that is executed once all of sstate has been
> unpacked, so ordering isn't a problem. The logic to add explicit
> dependencies isn't required anymore.
>
> Of course native dependencies are not as neat as target dependencies which
> is something I'd really like to see fixed, but in general I can't
> understand why this happens for you: if gdk-pixbuf-native can be extracted
> from sstate then all of its dependencies must have been too, and they
> include recipes such as libxdmcp-native.  If the dependencies need a
> rebuild then gdk-pixbuf should need a rebuild too...
>
> A full cooker log with the bug would be appreciated, but I know that's
> unlikely to happen!
>
> Ross
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20161014/dfe29503/attachment-0002.html>