[poky] perl binary hard-code path hurts sstate

[Tian, Kevin]

>From: Tian, Kevin
>Sent: Tuesday, December 21, 2010 9:10 AM
>
>>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:

Hi, Gary, I can't reproduce in my side, though I use only one machine.

>>   * 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

compare to your steps, mine is:

* build Poky in $DIR1, with sstate generated in ${SSTATE-CACHE} (a global one)
* then with same $POKYBASE, create a new build $DIR2, with SSTATE_MIRRORS
pointing to ${SSTATE-CACHE}
* move $DIR1 to $DIR1.bak

This way if there's reference to $DIR1, I should be able to observe failure

>>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.

However I didn't see above failure and most sstate packages could be reused
successfully except several ones depending on perl-native...

>>
>>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.

so Gary, could you try latest poky master or verify whether my single-machine steps
may expose same failure in your side? Or is there any step not equivalent between
our cases?

Thanks
Kevin