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
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!
Openembedded-core mailing list