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.bur...@intel.com> wrote: > > 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! > > Ross >
-- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
