[poky] perl binary hard-code path hurts sstate

[Tian, Kevin]

(change the title to better reflect the ongoing thread)

sstate.bbclass solves the absolute path issue by encoding a special pattern
(FIXMESTAGINGDIR) in all sysroot paths captured in plain text files (headers, 
config files, etc.), and then replace them with new path when installing into a 
different directory. This works well until below issue is reported.

The problem is that perl includes absolute path inside its binary:
	xxx/usr/lib/perl/5.8.8/CORE/libperl.so
(Nitin, please correct me whether this is the actual case)

I'm not sure how to work around it to allow a successful sstate reuse.

On the other hand, perhaps we could introduce some blacklist to mark some
packages not sstate-able? I think such case is rare. After rebuilding perl from
scratch in the new build dir, the error disappears and the build is continuing.
I'll see whether there're other similar issues cross the build.

Paul tried two machine before. I guess this issue doesn't expose earlier perhaps
because he is using same build hierarchy on two machines...

Thanks
Kevin

>From: Tian, Kevin
>Sent: Friday, December 17, 2010 12:47 PM
>
>>From: Garman, Scott A
>>Sent: Friday, December 17, 2010 10:30 AM
>>
>>On 12/16/2010 06:19 PM, Tian, Kevin wrote:
>>>> I'm guessing Perl creates a configuration file somewhere in the sysroot
>>>> which contains full pathnames to it's Perl module directories. That
>>>> config file gets rolled into the prebuild package and cannot be used on
>>>> another build directory.
>>>>
>>>
>>> I think so, just curious how it may be reproduced in my side. I just have one
>>> linux box in front now. :/
>>>
>>> Or could you search which file @INC actually points to and its content?
>>
>>It appears that @INC is encoded into the perl interpreter itself. cd
>>into your native sysroot directory and run ./usr/bin/perl -V
>>
>>To reproduce this, bitbake an image in one directory. Then, create a
>>separate directory somewhere else, and copy your sstate-cache over to
>>the second build area. Finally (and this is important), rename your
>>original build area.
>>
>>I'd bet that will make this reproducable.
>>
>
>I assume that you're not using the latest master, correct? I'm asking here as I
>encountered other errors earlier than this one due to a 'noexec' change from RP
>yesterday, and thus your info would confirm my guess. :-)
>
>Then after revert that commit, now I do reproduce this with same error as yours,
>except that it happens on git-native. This is understood as I think all perl related
>scripts will hit this issue.
>
>However I haven't found which bit contains that bad link pointing to original build
>directory. I checked tmp/sysroot/i686-linux/usr/lib/perl/5.8.8/Config.pm, where
>all hard paths are changed to new build directory correctly... :/
>
>Thanks
>Kevin
>_______________________________________________
>poky mailing list
>poky at yoctoproject.org
>https://lists.yoctoproject.org/listinfo/poky