[poky] perl binary hard-code path hurts sstate

[Tian, Kevin]

>From: Gary Thomas [mailto:gary at mlbassoc.com]
>Sent: Tuesday, December 21, 2010 11:14 PM
>
>On 12/21/2010 05:30 AM, Gary Thomas wrote:
>> 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
>>
>
>Still fails.  There is one step I wasn't clear on - if you
>just follow the steps above, you'll succeed and get a working
>result, using only the staged (sstate cached) packages.  However,
>if you try and build some other package, or in my case I forced
>a build of the kernel, it fails.
>
>Amended steps to reproduce this failure:
>   * Build Poky on MachineA, results in MachineA:NEW1
>   * Copy MachineA:NEW1/sstate-cache to MachineB:NEW1_CACHE
>   * Build Poky on MachineB, results in MachineB:NEW2, using
>     MachineB:NEW1_CACHE for SSTATE_MIRRORS
>   * Disable SSTATE_MIRRORS in conf/local.conf on MachineB:NEW2
>   * Build a package from scratch.  In my case, I rebuilt the kernel:
>     - bitbake virtual/kernel -c clean
>     - rm sstate-cache/sstate-linux-am*
>     - bitbake virtual/kernel
>     My kernel is based on a local recipe linux-am_X.Y.Z
>
>     Note: I tried to simplify this process by using 'cleanall'
>     but ran into a fetch problem (reported separately)

I finally found the 2nd machine and followed the exact steps as above based on
same commit you provided. Again, I can't reproduce your problem, and everything
works fine by trying fresh build for several recipes including kernel.

I'm not sure how much you have added in your own layer (like your own kernel
here), and it'd be helpful if you could try a pure poky master (and if possible a
single machine test to ease future replication).

BTW, my MachineA is Ubuntu9.04 and MachineB is FC13. Both are 32bit.

In your specific case, could you double-confirm whether libgcc.a exists in your
MachineB, and provide some info how you identified MachineA is referenced
for that library?

Thanks
Kevin

>
>Notes:
>   * For my testing, I used a simple package set, e.g. poky-image-minimal
>   * My Poky tree is based on today's master
>4cd40dbaa8aef7b6b9ff9ce892a576b802f4b1ec
>   * I notice that this process now rebuilds some 20 packages from scratch
>     on MachineB.  These include the perl-native, etc, that this thread has
>     been discussing.  Is this expected?
>
>Thanks for working on this; it's getting close and will be
>a big help to my customers.
>