[poky] perl binary hard-code path hurts sstate

Tian, Kevin kevin.tian at intel.com
Wed Dec 22 05:42:19 PST 2010


>From: Tian, Kevin
>Sent: Wednesday, December 22, 2010 9:39 PM
>
>>From: Gary Thomas [mailto:gary at mlbassoc.com]
>>Sent: Wednesday, December 22, 2010 8:35 PM
>>
>>On 12/22/2010 05:07 AM, Tian, Kevin wrote:
>>> Hi, Gary,
>>>
>>> I caught another bug when I did "bitbake virtual/kernel" following your instructions,
>>> of course with a slightly change adapting to my single machine case (I ensure my
>>> original build dir is renamed and also the PSTATE_MIRRORS is commented). It's
>>> about CFLAGS used to compile perf tool, which however is very 'perf' specific which
>>> I'm still looking for a right fix.
>>>
>>> I did try other recipes though, both native (gzip-native) and target recipes (db,
>>> makedevs, ...) which all works as expected. This is quite different from your error
>>> which I think is common blocking all target recipes in your side.
>>>
>>> So when I'm tackling the 'perf' issue, could you post your logs in case we can
>>> eye-catch some hints there? I think both the 1st build and 2nd failure log are useful
>>> here.
>>>
>>> In general as I replied in earlier mail, your error is very likely to be related to the
>>> fact that one or some of gcc recipes got rebuild in your experiment, which need
>>> verification from your log and I don't quite understand yet. :-)
>>
>>No GCC packages were rebuilt as part of my experiment.  Note that
>>I could have just as easily reproduced it by bumping PR in my kernel
>>recipe on the second machine, just to force it to be rebuilt.
>>
>>The problem here is that the GCC built on the first machine (used
>>as basis of the sstate-cached packages) has some hard-coded paths
>>in it which don't exist on the second machine.  Any package built
>>using that cross compiler could suffer this error.
>
>GCC always contains some hard links to original build dir, through --with-sysroot
>or --with-build-sysroot as the default config. Poky encapsulates ${CC} with
>"--sysroot=${STAGING_DIR_TARGET} to override build config to actual target
>sysroot, which should also work in 2nd build dir if it's set correctly. In my failure,
>the Makefile of kernel perf tool overrides ${CC} directly which makes --sysroot
>abandoned and then failed to search some header files.
>
>so your case looks weird to me. Just double confirm, any recipe in your
>2nd build now will fail following same steps, right?
>
>>
>>It turns out my list of packages rebuilt by perl-native _was_ 10.
>
>that's same list as what I observed so far.
>
>>My test count was just too stupid:
>>   % ls -l tmp/work/*/*/temp/log.do_compile* | wc
>>which sadly included the symlinks.  Leaving the symlinks out, I
>>got this package set:
>>    armv7a-poky-linux-gnueabi/libtool-cross-2.4-r0
>>    my_board-poky-linux-gnueabi/my-console-image-1.0-r0
>>    i686-linux/git-native-1.7.3.2-r0
>>    i686-linux/libxml2-native-2.7.7-r2
>>    i686-linux/libxslt-native-1.1.26-r0
>>    i686-linux/openssl-native-0.9.8p-r2
>>    i686-linux/perl-native-5.8.8-r14
>>
>i686-linux/pseudo-native-0.0+git0+c9792c7acdb1cac90549ff08db12a8bf0c53cdcf-r16
>>    i686-linux/python-native-2.6.6-nk0.0
>>    i686-linux/rpm-native-5.1.10-r7
>
>In the build where you see above kernel failure, is the kernel the only one
>being rebuilt, or are there any other packages rebuild triggered implicitly?
>
>I'll try to find a 2nd machine tomorrow...
>

In the meantime, could you also help do an experiment on a single machine? You
just need to make sure that the 1st build dir is renamed before the 2nd build
starts. Then the rest steps could be same as your original instructions. This should
help narrow this issue down further. :-)

Thanks
Kevin



More information about the poky mailing list