On 06/02/2011 07:37 AM, Phil Blundell wrote:
> On Thu, 2011-06-02 at 07:25 -0700, Tom Rini wrote:
>> 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.
>
> Ah right, I think I see what you're getting at now.
>
> If we've got a clean separation between perl-native and host perl,
> though, can't we now just eliminate all of that futzing with PERL5LIB in
> cpan.bbclass and such like places? perl-native already knows how to
> look in the right places within the sysroot for its modules so there
> should be no need for anything else to be overriding it.
Well, my question is, does it, really? Even if we're using the sstate
cache from /foo/oecore/tmp over in /bar/oecore/tmp (and /foo/oecore/tmp
is rm -rf'd) ? Since we've got a create_wrapper around perl and
perl${PV} it should be I suppose (or is easily added there), but I'd
feel a lot better with some testing of the above case (and the updates
to cpan*bbclass).
--
Tom Rini
Mentor Graphics Corporation
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
