[yocto] sstate black hole?
Martin Jansa
martin.jansa at gmail.com
Mon Jun 15 07:21:10 PDT 2015
On Mon, Jun 15, 2015 at 07:35:20AM -0600, Gary Thomas wrote:
> I'm working with i.MX6 targets (meta-fsl-arm*). For these
> targets, some packages are "special" in that they use i.MX6
> specific graphics support. This ends up with an additional
> layer of stratification, so my tmp/work tree has:
> all-amltd-linux
> cortexa9hf-vfp-neon-amltd-linux-gnueabi
> cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi
> teton_p0382-amltd-linux-gnueabi
> x86_64-amltd-linux-gnueabi
> x86_64-linux
>
> The packages that are built in tmp/work/cortex* are architecture
> specific, not target specific, hence my question:
>
> If I build for two i.MX6 targets, identical in every way
> except for the ${MACHINE} name, if I use sstate to share
> the builds from target A when building for target B, why
> are the packages built in cortexa9hf-vfp-neon-mx6qdl-amltd-linux-gnueabi
> not shared by sstate? I can see that they are present in
> the sstate cache, but they are always rebuilt for target B.
> I consider this incorrect behaviour as these are the same
> architecture and so they should be sharable via sstate.
>
> Am I missing something here? How can I determine why the
> package from target A (sstate cache) is not usable by target B?
Use openembedded-core/scripts/sstate-diff-machines.sh to check if the
signatures of the recipes you expect to be re-used are the same.
--
Martin 'JaMa' Jansa jabber: Martin.Jansa at gmail.com
More information about the yocto
mailing list