Re: perl binary hard-code path hurts sstate

[Gary Thomas <gary@mlbassoc.com>]

On 12/17/2010 06:58 AM, Richard Purdie wrote:
> On Fri, 2010-12-17 at 06:49 -0700, Chris Larson wrote:
>> These sorts of issues aren't new, or fun, sadly.  We've run into many
>> like this using packaged staging.  We had to use the variable to
>> disable packaged-staging for exactly this reason, so something similar
>> for sstate would indeed be useful for this.
>
> In cases like this I'd suggest adding the encoded path into the checksum
> via vardeps. This means the sstate package will be reused when the path
> matches but not otherwise.
>
> We can then work on removing the dependencies which I agree is the goal
> but we should get them identified first.

Sadly, this problem is not confined to perl.  I just tried this experiment:
   * Build Poky on MachineA to some directory $NEW
   * Copy Poky ($POKYBASE) and $NEW/sstate-cache to MachineB, in this case
     the path for $POKYBASE is the same on both machines but $NEW differs.
     MachineA:$NEW does not exist on MachineB
   * Try to build on Machine B, pointing SSTATE_MIRRORS to $NEW/sstate-cache
     This build is in $NEW2
The process fails for me building the kernel:
   | arm-poky-linux-gnueabi-ld: libgcc.a: No such file: No such file or directory
Looking carefully, I can see that the compiler is looking for libgcc.a in
the directory path $NEW that is only on MachineA.

So this is the same problem Paul had, just for the cross compiler
instead of perl.

n.b. Is there a bug # I should use to be tracking this?

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