On 06/02/2011 09:35 AM, Richard Purdie wrote:
> On Thu, 2011-06-02 at 09:28 -0700, Tom Rini wrote:
>> 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?
>
> If it doesn't it really does need to get fixed. I've not seen any
> evidence this has been the problem but it still could be.
I agree it needs to be fixed, yes. One way or another...
>> 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).
>
> I only took the perl-native DEPENDS patch on the condition this gets
> fixed properly. The patches that are there look to do that, at least for
> OE-Core. If there are further issues we're going to have to take them as
> they arise as I have an objection to crippling the build dependencies
> because perl is broken. Really this could use some TLC from someone with
> experience in the area...
Well, I guess I'd boil down what I said above into a request like this
for v3:
- Modify cpan.bbclass to NOT set PERL_INC / PERL_LIB / PERL_ARCHLIB /
PERLHOSTLIB.
- In /scratch/oecore/tmp0 build the images that were built for v1
- In /scratch/oecore/tmp1 build perl-native's full sstate cache.
- Keep the sstate cache from tmp1 and otherwise rm -rf tmp1.
- In /scratch/oecore/tmp2 using the sstate from tmp1, build the same
images that were built for tmp0.
If all of that works, I think we can call this safe enough for now and
possibly even really fixed, while we have someone actively kicking
around the recipes in question.
--
Tom Rini
Mentor Graphics Corporation
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
