On 11 October 2016 at 17:44, Kyle Russell <bkyleruss...@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!
Openembedded-core mailing list