[yocto] sstate black hole?

[Nikolay Dimitrov]

Hi Gary,

On 06/15/2015 04:35 PM, 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?

Are these packages (the ones that are getting rebuilt) depending on
machine-specific headers (kernel)?

Regards,
Nikolay