Re: perl binary hard-code path hurts sstate

[Gary Thomas <gary@mlbassoc.com>]

On 12/21/2010 04:51 AM, Tian, Kevin wrote:
>> 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?

Yes, I'll try it now, thanks

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