[poky] perl binary hard-code path hurts sstate

[Tian, Kevin]

>From: Gary Thomas
>Sent: Friday, December 17, 2010 11:09 PM
>
>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?
>

I'll see whether I can reproduce this after RP's new fix about perl-native.

Thanks
Kevin