[yocto] sstate black hole?

[Gary Thomas]

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?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------