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 LeithauserThread Previous | Thread Next