[OE-core] [RFC v1 PATCH 00/16] populate perl-native into its own directory

Tom Rini tom_rini at mentor.com
Thu Jun 2 14:25:45 UTC 2011


On 06/02/2011 07:06 AM, Richard Purdie wrote:
> On Wed, 2011-06-01 at 13:59 -0700, Tom Rini wrote:
>> On 06/01/2011 01:45 PM, Phil Blundell wrote:
>>> On Wed, 2011-06-01 at 13:42 -0700, Tom Rini wrote:
>>>> What falls down in this case is that  once
>>>> perl-native is built (and in our PATH), if it's a different version than
>>>> system-wide perl, stuff starts failing on version mis-match.
>>>
>>> I think that's the bit that I'm not properly understanding.  Which
>>> versions are mismatching, exactly?  
>>>
>>> Surely the local perl from the sysroot ought to be completely
>>> self-contained and shouldn't be using any bits from the host perl
>>> install at that point.
>>
>> So this jogs my memory a bit!  It's not so much perl itself but stuff
>> that uses perl that can get dirty and then no, you have stuff thats
>> built for system perl and stuff that's built with perl-native clashing.
>>
>> Relying even more on memory, I think help2man was one of the "easy"
>> culprits and since we also modify the env, we do things like have
>> help2man run with PERL5LIB and so on pointing system-wide perl at
>> perl-native's lib directory and so forth.
> 
> But with the proposed patch series either:
> 
> a) help2man depends perlnative.bbclass
> 
> In this case it can depend on perl-native being there, its in path and
> things work as per OE.dev.
> 
> b) help2man doesn't depend in perlnative.bbclass
> 
> It only sees the system perl.
> 
> So I'm still not clear where the problem is?

Well, help2man-native is (or needs to be) a dep listed in
autotools.bbclass (since so many things need it, hence why it oe-core
still just has it as a required host utility instead of building it).

But help2man is just the easy/common case.  Heck, it _may_ blow up even
with the host help2man instead of help2man-native, if a recipe uses
system-wide help2man and perlnative.bbclass.  The root problem (again,
from memory) is that since we modify PERL5LIB and so on, when we do
that, we've opened ourselves up for system-wide perl trying to use
perl-native's stuff.

-- 
Tom Rini
Mentor Graphics Corporation




More information about the Openembedded-core mailing list