develooper Front page | perl.perl5.porters | Postings from June 2013

Re: [perl #118671] t/comp/parser.t loads utf8.pm from installed perl

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
June 28, 2013 23:42
Subject:
Re: [perl #118671] t/comp/parser.t loads utf8.pm from installed perl
Message ID:
9FF467F7-8415-4794-9CAB-D13F8BE5E058@mac.com

On Jun 28, 2013, at 6:14 PM, James E Keenan via RT <perlbug-followup@perl.org> wrote:
> 
> I didn't get quite the same output as you did.  This was build with
> -DDEBUGGING on dromedary:
> 

Thanks, James, but there is a key point that I didn't explain fully.  To trigger the problem, you *must* already have an installed perl that matches exactly the library locations of the perl you are testing (but have not yet installed).  So if you do this command in your dirty build directory:

$ grep PRIVLIB config.h

you'll see one of the locations that S_incpush and friends in perl.c will load into @INC.  In my case I see:

#define PRIVLIB "/usr/local/lib/perl5/5.19.2"		/**/

so I would only hit the problem if I've previously installed a perl whose libraries go in /usr/local/lib/perl5/5.19.2.  

If the last component were 5.19.1 rather than 5.19.2 in what I've previously installed, the problem wouldn't show up.  The tests would do some unnecessary churn looking for libraries in directories that don't exist, but no invalid results would be produced.  

Well, that's assuming there is valid fall-back code to DTRT with C<chr 0x387;> when no utf8.pm can be loaded, and I really have no idea whether that's the case.  But at least we wouldn't be pulling in the *wrong* utf8.pm (and utf8_heavy.pl, etc.).

________________________________________
Craig A. Berry
mailto:craigberry@mac.com

"... getting out of a sonnet is much more
 difficult than getting in."
                 Brad Leithauser


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About