<div dir="ltr">Thanks for your response Alex.<div><br></div><div>Below is an excerpt of one failure I've encountered. When attempting to do_rootfs, the following error occurs:</div><div><br></div><div><div>error while loading shared libraries: libopkg.so.1: cannot open shared object file: No such file or directory</div><div><br></div>Below is more detail:<br class="inbox-inbox-Apple-interchange-newline"><br><div>NOTE: recipe core-image-biamp-linux-ppc-1.0-r0: task do_rootfs: Started</div><div>ERROR: Unable to update the package index files. Command '/var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/tmp/sysroots/x86_64-linux/usr/bin/opkg-cl -f /var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/tmp/work/mpc83xx-poky-linux/core-image-biamp-linux-ppc/1.0-r0/opkg.conf -o /var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/tmp/work/mpc83xx-poky-linux/core-image-biamp-linux-ppc/1.0-r0/rootfs --force_postinstall --prefer-arch-to-version --add-exclude linux-dummy --add-exclude opkg --add-exclude dbus --add-exclude gdbm --force-overwrite update' returned 127:</div><div>/var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/tmp/sysroots/x86_64-linux/usr/bin/opkg-cl: error while loading shared libraries: libopkg.so.1: cannot open shared object file: No such file or directory</div><div>ERROR: Function failed: do_rootfs<br></div><div>ERROR: Logfile of failure stored in: /var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/tmp/work/mpc83xx-poky-linux/core-image-biamp-linux-ppc/1.0-r0/temp/log.do_rootfs.4871</div><div>NOTE: recipe core-image-biamp-linux-ppc-1.0-r0: task do_rootfs: Failed</div><div>ERROR: Task 7 (/var/lib/jenkins/workspace/SingleNetworkConnectionPipeline/repos/poky/ppc/build-biamp-linux-ppc/../meta-biamp/recipes-ppc/images/<a href="http://core-image-biamp-linux-ppc.bb">core-image-biamp-linux-ppc.bb</a>, do_rootfs) failed with exit code '1'</div><div><br></div><div>When I execute ldd on opkg-cl, I get the following:</div><div><span style="white-space:pre"> </span>linux-vdso.so.1 (0x00007ffda9bd8000)</div><div><span style="white-space:pre"> </span>libopkg.so.1 => not found</div><div><span style="white-space:pre"> </span>libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f72dbac3000)</div><div><span style="white-space:pre"> </span>/lib64/ld-linux-x86-64.so.2 (0x00007f72dc067000)</div><div><br></div><div>Looking inside the tmp/sysroots directory, I can find libopkg.so.1. It appears as though opkg-cl was built to look for the shared library in the host path rather than the tmp/sysroots path.</div><div><br></div><div>My guess is that this is something other than an sstate-cache problem but when I clear the sstate-cache, everything builds fine. </div><div><br></div><div>Nick</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Aug 28, 2018 at 12:10 AM Alexander Kanavin <<a href="mailto:alex.kanavin@gmail.com" target="_blank">alex.kanavin@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2018-08-28 7:53 GMT+02:00 Nick Winters <<a href="mailto:nick@wintersteam.org" target="_blank">nick@wintersteam.org</a>>:<br>
> Often when I use an sstate cache from another build, I run into problems<br>
> where builds fail. Usually the failure is a result of not being able to find<br>
> a shared library. If I delete the sstate cache, the build succeeds, although<br>
> it is 8 hours later. I switched to using sstate mirrors and had similar<br>
> problems.<br>
<br>
If you provide an example of a specific failure, we might be better<br>
able to help you.<br>
<br>
It's fine to use one global sstate cache for absolutely everything.<br>
You can share between builds, target machines and distros.<br>
<br>
Alex<br>
</blockquote></div></div></div>