Front page | perl.vmsperl |
Postings from December 2001
Re: [PATCH lib/ExtUtils/MM_Unix.pm] miniperl found before perl?
Thread Previous
|
Thread Next
From:
Michael G Schwern
Date:
December 17, 2001 16:19
Subject:
Re: [PATCH lib/ExtUtils/MM_Unix.pm] miniperl found before perl?
Message ID:
20011218001904.GK17232@blackrider
On Mon, Dec 17, 2001 at 08:45:26AM -0500, PPrymmer@factset.com wrote:
>
> Michael G Schwern wrote:
>
> > $ show symbol miniperl
> > %DCL-W-UNDSYM, undefined symbol - check validity and spelling
> > $ show symbol perl
> > PERL == "$PERL_ROOT:[000000]PERL.EXE"
> > $ show symbol perl_root
> > %DCL-W-UNDSYM, undefined symbol - check validity and spelling
>
> This was the wrong command to use. From DCL their is a
> distinction between symbols and logical names (although
> the C RTL, and some versions of perl blur the distinction
> through getenv() and %ENV). You instead want to run:
>
> $ show logical perl_root
>
> Not `show symbol`.
Ok, I get the proper perl_root now, but still no miniperl.
$ show logical miniperl
%SHOW-S-NOTRAN, no translation for logical name MINIPERL
$ show symbol miniperl
%DCL-W-UNDSYM, undefined symbol - check validity and spelling
$ show symbol perl
PERL == "$PERL_ROOT:[000000]PERL.EXE"
$ show logical perl_root
"PERL_ROOT" = "USER1:[SCHWERN.SRC.BLEADPERL.]" (LNM$PROCESS_TABLE)
> > which is odd because I know its set.
> >
> > $ perl -v
> >
> > This is perl, v5.7.2 built for VMS_AXP
> > (with 1 registered patch, see perl -V for more detail)
> >
> > Copyright 1987-2001, Larry Wall
> >
> > Perl may be copied only under the terms of either the Artistic License or the
> > GNU General Public License, which may be found in the Perl 5 source kit.
> >
> > Complete documentation for Perl, including FAQ lists, should be found on
> > this system using `man perl' or `perldoc perl'. If you have access to the
> > Internet, point your browser at http://www.perl.com/, the Perl Home Page.
> >
> > $ perl makefile.pl
> > Test::Harness likes to have Devel::CoreStack, but doesn't require it.
> > Checking if your kit is complete...
> > Looks good
> > Writing Descrip.MMS for Test::Harness
> > $ mmk test
> > miniperl "-Iperl_root:[lib]" "-MExtUtils::Install" -e "pm_to_blib({split(' ',<STDIN>)},'[.blib.lib.auto]','')" <.MM_tmp
> > Perl 5.006001 required--this is only version 5.00503, stopped at /perl_root/lib/ExtUtils/Install.pm line 3.
> > BEGIN failed--compilation aborted at /perl_root/lib/ExtUtils/Install.pm line 3.
> > BEGIN failed--compilation aborted.
> > %SYSTEM-F-ABORT, abort
> > %MMK-F-ERRUPD, error status %X0000002C occurred when updating target PM_TO_BLIB.TS
> >
>
> The miniperl invoked here is likely a descrip.mms macro. The version
> mismatch is odd assuming your PERL_ROOT and PERLSHR logical names
> point only at an install of 5.6.1. You did BTW run `mms install` (or
> `mmk install`)? Also try running `show log perl*`.
No, I'm running straight out of the bleadperl build directory. Even
so, where is that 5.00503 coming from? There is a miniperl.exe in my
PERL_ROOT but its a binary.
$ show logical perlshr
"PERLSHR" = "PERL_ROOT:[000000]PERLSHR.EXE" (LNM$PROCESS_TABLE)
$ show log perl*
(LNM$PROCESS_TABLE)
"PERLSHR" = "PERL_ROOT:[000000]PERLSHR.EXE"
"PERL_ROOT" = "USER1:[SCHWERN.SRC.BLEADPERL.]"
(LNM$JOB_810FC540)
(LNM$GROUP_000201)
(LNM$SYSTEM_TABLE)
(LNM$SYSCLUSTER_TABLE)
> > > Perhaps your PERL_ROOT logical name points to a 5.005_03 build
> > > directory (or possibly such a directory is in your path). But that
> > > should only happen if you were running Makefile.PL with 5.005_03.
> > > Were you?
> >
> > No, I was running it with bleadperl where PERL_ROOT points to the
> > bleadperl build directory. I do have a 5.005_03 lying around
> > somewhere, though. My environment is a little screwy, that might be
> > the problem.
>
> This is actually a test that was done informally in the past: ensure
> that a definition of a previous perl installation did not interfere
> with a new build. You've taken it to the building of additional modules
> though. Are you building the extension outside of your PERL_ROOT tree?
Yes. USER1:[SCHWERN.SRC.TEST-HARNESS-2_0005]. Is this Bad?
> > You guys have to get out of the habit of treating test failures as
> > normal, at least when I'm around. What were those failures?
>
> Rare is the CPAN Makefile.PL that is written with C<use File::Spec;>
> and rare is the CPAN Makefile.PL that fails to build on Unix and Windows
> as a result. By and large the porting of CPAN modules is done on
> a small scale as-needed basis.
My modules are rare. I have a VMS account and I'm not afraid to use
it. Report all test failures please, they will get fixed to the best
of my abilities.
And rare does the unreported bug get fixed. Don't accept failures as
just part of the norm on vmsperl, and don't assume the author doesn't
care. Report the bug so the author can do something about it. If
nothing is done, you're no worse off than when you started.
Squeaky wheel and all that.
--
Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
Perl Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
Sometimes you eat the path, sometimes the path eats you.
Thread Previous
|
Thread Next