Re: problem building perl 5.10.1
Hi. Thanks for answer and sorry for the late in replay but I was on
holiday.
About the test:
$rc = system { lskdfj } lskdfj;
unless( ok($rc == 255 8 or $rc == -1 or $rc == 256 or $rc == 512) ) {
print # \$rc == $rc\n;
}
I don't understand very well what I should do for trying running the
test independently how you suggested me.
Anyway if I comment the other tests and I run this test alone with
@[.vms]test .exe -v [.op]exec.t, I don't see anything but it
confirm that is this test that failed:
# Failed at [.op]exec.t line 13
not ok 1
t/OP/EXECFAILED at test 1
Failed 1 test out of 0, 0.00% okay.
[.OP]EXEC.T
What the test is trying to do is run a nonsense command in a
subprocess and verify that the return value is set appropriately. If
that command happens not to be nonsense on your system, that could
cause trouble, so you might see what this gives you:
$ LSKDFJ
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\LSKDFJ\
If I give the command LSKDFJ I obtain:
ISTI-MX4 LSKDFJ
%DCL-E-PARSEFAIL, error parsing DCL$PATH:LSKDFJ.*
-RMS-F-DEV, error in device name or inappropriate device type for operation
###
ISTI-MX4 @[.vms]test .exe -v
$1$DGA100:[00.PERL-5_10_1.lib]vmsish.t
ok 21 - use vmsish qw(time)
not ok 22 - (time) UTC: 1280511919 VMS: 1280519119
t/$1$DGA100/PERL-5_10_1/LIB/VMSISHFAILED at test 22
Failed 1 test out of 1, 0.00% okay.
$1$DGA100:[00.PERL-5_10_1.LIB]VMSISH.T
You might check the timezone settings and timezone logicals on your
system:
$ show logical *timezone*
The time values here indicate you are 2 hours (7200 seconds) ahead of
UTC -- is that correct?
No, the show logical timezone command indicate that I am one hour
ahead of UTC:
SYS$TIMEZONE_DIFFERENTIAL = 3600
but if I give the show time command I obtain a value two hour ahead of
UTC (it is correct because in this period we use the CEST).
Regards
Re: problem building perl 5.10.1
On Aug 2, 2010, at 4:40 AM, Fabio Ciampi wrote:
$ show logical DECC$*
I have only the default DECC$ feature logicals:
DECC$CRTLMAP = SYS$SHARE:DECC$SHR
DECC$SHR_AV = DECC$SHR
OK, good. Those aren't actually feature logicals, so won't cause any
trouble.
ISTI-MX4 show process/quota
quotas snipped
I don't see any obvious problems here.
This time the mmk test process execute completely and the tests
concerning the compression utility work fine.
That's excellent. You very likely have a Perl that will do everything
you need it to.
Anyway I have some other tests failed:
Failed 9 tests out of 1550, 99.42% okay.
[-.lib.Archive.Extract.t]01_Archive-Extract.t
[-.lib.CPANPLUS.t]03_CPANPLUS-Internals-Source.t
[-.lib.CPANPLUS.t]15_CPANPLUS-Shell.t
[-.lib.ExtUtils.t]cp.t
[-.lib.ExtUtils.t]pm_to_blib.t
[-.lib.Module.Build.t]debug.t
[-.lib.Module.Build.t]tilde.t
[-.lib]vmsish.t
op/exec.t
This is a pretty darn good score. I wouldn't both with the module
test failures without checking for newer versions of the modules on
CPAN or grabbing a Perl version (like 5.12.1) that includes newer
versions of the modules.
Following more information about the failure of the tests:
About the test:
$rc = system { lskdfj } lskdfj;
unless( ok($rc == 255 8 or $rc == -1 or $rc == 256 or $rc ==
512) ) {
print # \$rc == $rc\n;
}
I don't understand very well what I should do for trying running the
test independently how you suggested me.
Anyway if I comment the other tests and I run this test alone with
@[.vms]test .exe -v [.op]exec.t, I don't see anything but it
confirm that is this test that failed:
# Failed at [.op]exec.t line 13
not ok 1
t/OP/EXECFAILED at test 1
Failed 1 test out of 0, 0.00% okay.
[.OP]EXEC.T
What the test is trying to do is run a nonsense command in a
subprocess and verify that the return value is set appropriately. If
that command happens not to be nonsense on your system, that could
cause trouble, so you might see what this gives you:
$ LSKDFJ
%DCL-W-IVVERB, unrecognized command verb - check validity and spelling
\LSKDFJ\
###
ISTI-MX4 @[.vms]test .exe -v $1$DGA100:
[00.PERL-5_10_1.lib]vmsish.t
ok 21 - use vmsish qw(time)
not ok 22 - (time) UTC: 1280511919 VMS: 1280519119
t/$1$DGA100/PERL-5_10_1/LIB/VMSISHFAILED at test 22
Failed 1 test out of 1, 0.00% okay.
$1$DGA100:[00.PERL-5_10_1.LIB]VMSISH.T
You might check the timezone settings and timezone logicals on your
system:
$ show logical *timezone*
The time values here indicate you are 2 hours (7200 seconds) ahead of
UTC -- is that correct?
Craig A. Berry
mailto:craigbe...@mac.com
... getting out of a sonnet is much more
difficult than getting in.
Brad Leithauser
Re: problem building perl 5.10.1
Hi Thanks to both for answers. I've have to change the machine on which install perl for reasons linked to production environment problems. Anyway I still have an IA64 Operating System (Version V8.3-1H1), ODS5 disk, MadGoat Make Utility V4.1. Instead I change my compiler; now I have HP C X7.3-289. @configure -des -Dprefix=DATE$MSA1:[PERL-5_10_1.] I have not used the -Dprefix. On VMS, I use logical names to determine which version of an application to run. Perl uses the logical name PERL_ROOT, regardless of what prefix that you assign. True, but irrelevant. On VMS, the prefix just determines what goes into the generated perl_setup.com to specify where Perl will be installed. Everything will still refer to perl_root, which will in turn point the directory specified by prefix. In theory, vms_prefix is configurable and would give you something other than perl_root; Don't Do That, though, as way too many things have evolved to depend explicitly on perl_root. This time, for semplicity, I didn't use any prefix; I only gave the command: @configure -des mmk mmk test The mmk process works (I only have some Warning: long symbol). During mmk test I saw some tests failed: t/op/exec.FAILED at test 16 ext/Compress-Raw-Bzip2/t/01bzip2..FAILED--expected 157 tests, saw 10 ext/Compress-Raw-Bzip2/t/09limitoutputFAILED--expected 88 tests, saw 5 ext/IO-Compress/t/001bzip2FAILED at test 58 ext/IO-Compress/t/006zip..FAILED--expected 77 tests, saw 17 Perl is sensitive to the logical name BIN, and foreign commands for ZIP and BZIP2 among others. Yes, the compression modules are sensitive to what compression utilities you have installed. The tests attempt to determine what's there and use it or work around it but often fail to do so correctly. I have modified the startup file in cluster$mgr directory to exclude my machine to take the symbol commands concerning compression utility. About the logical name BIN I don't have logical name assigned to it. For building and the initial testing of Perl, make sure that all the DECC$ feature logicals are set to their default. I would say check which, if any you have enabled and try turning them off. E.g. $ show logical DECC$* I have only the default DECC$ feature logicals: DECC$CRTLMAP = SYS$SHARE:DECC$SHR DECC$SHR_AV = DECC$SHR Quotas could, as John said, also be a problem. We don't have a complete or up-to-date list of what quotas you need, so maybe post the results of $ show process/quota 22-JUL-2010 13:59:09.33 User: CRAIGProcess ID: 0005B477 Node: ALMA Process name: _FTA6: Process Quotas: Account name: CAB CPU limit: Infinite Direct I/O limit: 1024 Buffered I/O byte count quota: 1999808 Buffered I/O limit:1024 Timer queue entry quota: 400 Open file quota:512 Paging file quota: 2993040 Subprocess quota:10 Default page fault cluster: 64 AST quota: 398 Enqueue quota: 4000 Shared file limit:0 Max detached processes:0 Max active jobs: 0 ISTI-MX4 show process/quota 30-JUL-2010 16:09:23.59 User: SYSTEM Process ID: 3F0004AE Node: MX4 Process name: _TNA3: Process Quotas: Account name: SYSTEM CPU limit: Infinite Direct I/O limit: 200 Buffered I/O byte count quota: 2999808 Buffered I/O limit: 200 Timer queue entry quota:2000 Open file quota:300 Paging file quota: 1492944 Subprocess quota:10 Default page fault cluster: 64 AST quota: 248 Enqueue quota: 2500 Shared file limit:0 Max detached processes:0 Max active jobs: 0 This time the mmk test process execute completely and the tests concerning the compression utility work fine. Anyway I have some other tests failed: Failed 9 tests out of 1550, 99.42% okay. [-.lib.Archive.Extract.t]01_Archive-Extract.t [-.lib.CPANPLUS.t]03_CPANPLUS-Internals-Source.t [-.lib.CPANPLUS.t]15_CPANPLUS-Shell.t [-.lib.ExtUtils.t]cp.t [-.lib.ExtUtils.t]pm_to_blib.t [-.lib.Module.Build.t]debug.t [-.lib.Module.Build.t]tilde.t [-.lib]vmsish.t op/exec.t ### Since not all tests were successful, you may want to run some of ### them individually and examine any diagnostic messages they produce. ### See the INSTALL document's section on make test. ### You have a good chance to get more information by running ### ./perl harness ### in the 't' directory since most (=80%) of the tests succeeded. u=69.33 s=0.00 cu=0.00 cs=0.00
Re: problem building perl 5.10.1
On Jul 19, 2010, at 8:45 PM, John E. Malmberg wrote:
Fabio Ciampi wrote:
@configure -des -Dprefix=DATE$MSA1:[PERL-5_10_1.]
I have not used the -Dprefix. On VMS, I use logical names to
determine which version of an application to run. Perl uses the
logical name PERL_ROOT, regardless of what prefix that you assign.
True, but irrelevant. On VMS, the prefix just determines what goes
into the generated perl_setup.com to specify where Perl will be
installed. Everything will still refer to perl_root, which will in
turn point the directory specified by prefix. In theory, vms_prefix
is configurable and would give you something other than perl_root;
Don't Do That, though, as way too many things have evolved to depend
explicitly on perl_root.
mmk
mmk test
The mmk process works (I only have some Warning: long symbol).
During mmk test I saw some tests failed:
t/op/
exec.FAILED at
test 16
ext/Compress-Raw-Bzip2/t/
01bzip2..FAILED--expected 157 tests,
saw 10
ext/Compress-Raw-Bzip2/t/
09limitoutputFAILED--expected 88 tests, saw 5
ext/IO-Compress/t/
001bzip2FAILED at test 58
ext/IO-Compress/t/
006zip..FAILED--expected 77
tests, saw 17
Perl is sensitive to the logical name BIN, and foreign commands for
ZIP and BZIP2 among others.
Yes, the compression modules are sensitive to what compression
utilities you have installed. The tests attempt to determine what's
there and use it or work around it but often fail to do so correctly.
This one is a bit more of a concern:
not ok 16
t/OP/EXECFAILED at test 16
Failed 1 test out of 1, 0.00% okay.
[.OP]EXEC.T
I believe what that's doing is:
$rc = system { lskdfj } lskdfj;
unless( ok($rc == 255 8 or $rc == -1 or $rc == 256 or $rc == 512) ) {
print # \$rc == $rc\n;
}
so you might try running that independently and see what happens.
For building and the initial testing of Perl, make sure that all the
DECC$ feature logicals are set to their default.
I would say check which, if any you have enabled and try turning them
off. E.g.
$ show logical DECC$*
I would do that first before debugging the individual tests.
Quotas could, as John said, also be a problem. We don't have a
complete or up-to-date list of what quotas you need, so maybe post the
results of
$ show process/quota
22-JUL-2010 13:59:09.33 User: CRAIGProcess ID: 0005B477
Node: ALMA Process name: _FTA6:
Process Quotas:
Account name: CAB
CPU limit: Infinite Direct I/O limit: 1024
Buffered I/O byte count quota: 1999808 Buffered I/O limit:1024
Timer queue entry quota: 400 Open file quota:512
Paging file quota: 2993040 Subprocess quota:10
Default page fault cluster: 64 AST quota: 398
Enqueue quota: 4000 Shared file limit:0
Max detached processes:0 Max active jobs: 0
and we'll go from there. Or check the documented quota requirements
for Java and they will be way more than enough for Perl :-).
I have built Perl many times using
$ cc/vers
HP C V7.3-019 on OpenVMS IA64 V8.3-1H1
without any of the problems you are seeing, so if we dig a bit into
the differences between your environment and mine we should be able to
get past this.
Thanks for the careful and complete problem report.
Craig A. Berry
mailto:craigbe...@mac.com
... getting out of a sonnet is much more
difficult than getting in.
Brad Leithauser
problem building perl 5.10.1
Hi I'm a newbie of VMS. I've tried to build perl 5.10.1 on my IA64 Operating System (Version V8.3-1H1) with ODS5 disks. I have MadGoat Make Utility V4.1 and compiler HP C V7.2-001. I gave the following commands after download perl sources and unpacked them: set security/protection=(o:rwed) perl-5^.10^.1.DIR;1 rename perl-5^.10^.1.DIR perl-5_10_1.DIR @configure -des -Dprefix=DATE$MSA1:[PERL-5_10_1.] mmk mmk test The mmk process works (I only have some Warning: long symbol). During mmk test I saw some tests failed: t/op/exec.FAILED at test 16 ext/Compress-Raw-Bzip2/t/01bzip2..FAILED--expected 157 tests, saw 10 ext/Compress-Raw-Bzip2/t/09limitoutputFAILED--expected 88 tests, saw 5 ext/IO-Compress/t/001bzip2FAILED at test 58 ext/IO-Compress/t/006zip..FAILED--expected 77 tests, saw 17 After the last test (006zip) the mmk test process doesn't go on and doesn't return the prompt. I have the same identical problem with the version 5.12.1. Following more information about the failure of the tests: ISTI-BLADE4 @[.vms]test .exe -v [.op]exec.t %DELETE-I-FILDEL, DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1.t]PERL.EXE;1 deleted (16 blocks) %COPY-S-COPIED, DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1]PERL.EXE;1 copied to DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1.T]PERL.EXE;1 (15 blocks) %DELETE-I-FILDEL, DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1.t]vmspipe.com;1 deleted (8 blocks) %COPY-S-COPIED, DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1]vmspipe.com;1 copied to DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1.T]vmspipe.com ;1 (2 blocks) 19-JUL-2010 17:24:00.29 User: SYSTEM Process ID: 3C0004B6 Node: BLADE4 Process name: SYSTEM Accounting information: Buffered I/O count: 82646 Peak working set size: 32176 Direct I/O count: 38127 Peak virtual size: 220736 Page faults: 178044 Mounted volumes:0 Images activated: 499 Elapsed CPU time: 0 00:00:31.28 Connect time: 0 01:52:53.29 1..22 ok 1 - interp system(EXPR) ok 2 - exited 0 ok 3 - split direct system(EXPR) ok 4 - exited 0 ok 5 - system(PROG, LIST) ok 6 - exited 0 ok 7 - piped echo emulation not ok 8 - no extra newlines on `` # TODO VMS sticks newlines on everything # Failed at [.op]exec.t line 82 # got 'ok # ' # expected 'ok' not ok 9 - no extra newlines on pipes # TODO VMS sticks newlines on everything # Failed at [.op]exec.t line 85 # got 'ok # ' # expected 'ok' not ok 10 - doubled up newlines # TODO VMS sticks newlines on everything # Failed at [.op]exec.t line 88 # got 'ok # # # ' # expected 'ok # # ' not ok 11 - extra newlines on inside pipes # TODO VMS sticks newlines on everything # Failed at [.op]exec.t line 91 # got 'ok # # ' # expected 'ok # ' not ok 12 - extra newlines on outgoing pipes # TODO VMS sticks newlines on everything # Failed at [.op]exec.t line 94 # got 'ok # # ' # expected 'ok # ' not ok 13 - ignore $/ when capturing output in scalar context # TODO VMS sticks newlines on everything # Failed at [.op]exec.t line 100 # got '1234 # ' # expected '1234' ok 14 - Explicit exit of 0 ok 15 - Explicit exit of 1 not ok 16 t/OP/EXECFAILED at test 16 Failed 1 test out of 1, 0.00% okay. [.OP]EXEC.T ### Since not all tests were successful, you may want to run some of ### them individually and examine any diagnostic messages they produce. ### See the INSTALL document's section on make test. u=31.45 s=0.00 cu=0.00 cs=0.00 scripts=1 tests=22 19-JUL-2010 17:24:07.53 User: SYSTEM Process ID: 3C0004B6 Node: BLADE4 Process name: SYSTEM Accounting information: Buffered I/O count: 83592 Peak working set size: 32176 Direct I/O count: 38222 Peak virtual size: 220736 Page faults: 178678 Mounted volumes:0 Images activated: 501 Elapsed CPU time: 0 00:00:31.46 Connect time: 0 01:53:00.53 %SYSTEM-F-ABORT, abort ISTI-BLADE4 @[.vms]test .exe -v DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1.ext.Compress-Raw-Bzip2.t]01bzip2.t;1 %DELETE-I-FILDEL, DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1.t]PERL.EXE;1 deleted (16 blocks) %COPY-S-COPIED, DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1]PERL.EXE;1 copied to DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1.T]PERL.EXE;1 (15 blocks) %DELETE-I-FILDEL, DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1.t]vmspipe.com;1 deleted (8 blocks) %COPY-S-COPIED, DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1]vmspipe.com;1 copied to DATL$MSA1:[DIR$UTIL.PERL_5-010.PERL-5_10_1.T]vmspipe.com ;1 (2 blocks) 19-JUL-2010 17:33:40.32 User: SYSTEM Process ID: 3C0004B6 Node: BLADE4 Process name: SYSTEM
Re: problem building perl 5.10.1
Fabio Ciampi wrote: Hi I'm a newbie of VMS. I've tried to build perl 5.10.1 on my IA64 Welcome to VMS. I see a couple of newbie mistakes below, but they probably are not causing the issues that you are seeing, just additional issues. And these are somethings that people with experience should have learned but many have not. Operating System (Version V8.3-1H1) with ODS5 disks. I have MadGoat Make Utility V4.1 and compiler HP C V7.2-001. I gave the following commands after download perl sources and unpacked them: set security/protection=(o:rwed) perl-5^.10^.1.DIR;1 rename perl-5^.10^.1.DIR perl-5_10_1.DIR @configure -des -Dprefix=DATE$MSA1:[PERL-5_10_1.] I have not used the -Dprefix. On VMS, I use logical names to determine which version of an application to run. Perl uses the logical name PERL_ROOT, regardless of what prefix that you assign. Newbie note 1: In general in managing VMS, physical device names should generally be referenced only in the startup procedures where logical names are mapped to them, and in utilities like backup or defragmenters that need to specifically operate on physical devices. Any applications other than the above that require a physical device name instead of a logical name is broken, and not properly written for VMS. Some applications have broken configuration routines that put physical device names in configuration files instead of logical names. In most cases, I have found that manually fixing the configuration files makes the application more maintainable. If I move the the application or its data to a new physical disk, all I should have to do is change how the logical names are mapped. I should never have to reconfigure an application for that. And I should never need to notify an end user when I change what physical devices that are being used by the computer or one of their applications. VMS uses logical names for things that Unix uses symbolic links for, but logical names are far more powerful and flexible. mmk mmk test The mmk process works (I only have some Warning: long symbol). During mmk test I saw some tests failed: t/op/exec.FAILED at test 16 ext/Compress-Raw-Bzip2/t/01bzip2..FAILED--expected 157 tests, saw 10 ext/Compress-Raw-Bzip2/t/09limitoutputFAILED--expected 88 tests, saw 5 ext/IO-Compress/t/001bzip2FAILED at test 58 ext/IO-Compress/t/006zip..FAILED--expected 77 tests, saw 17 Perl is sensitive to the logical name BIN, and foreign commands for ZIP and BZIP2 among others. Older versions of the GNV product would incorrectly assign the logical name BIN in the system table, and many people will put in symbols for ZIP and BZIP2 in the SYLOGIN.COM or LOGIN.COM. Other applications may set the BIN logical name and leave it behind. If some of the tests find a ZIP or BZIP executable, they will try to use it just like a UNIX utility and may expect that they are running it under the Bash shell. Perl also now supports the DECC$* feature logicals at run time. Not all combinations have been tested, and some combinations will cause tests to fail because they change the behavior in ways that the tests do not yet expect. It is also possible that running on your environment may need some more quota for a resource than the build procedure knows to test for. For building and the initial testing of Perl, make sure that all the DECC$ feature logicals are set to their default. Then read the two VMS specific text files in Perl for their usage. Newbie note 2: [DIR$UTIL.PERL_5-010.PERL-5_10_1]PERL.EXE;1 The use of '$' in logical names, filenames, directories, and symbols is reserved to HP/VMS and registered third party usage. It should not be used in names that you make up for your own use unless directed to by the either the VMS or third party that has registered the prefix for that name. This is a long standing rule in VMS, but it used to be easier to find in the documentation. This prevents your names and names from HP or layered products from having a conflict. There is documentation in the VMS doc set on getting those names registered by application developers. With all the possibilities out there, the odds of a conflict of making up your own names with $ in them are low, but it is not zero. Some layered products use undocumented prefixed logical names to enable debugging or other diagnostic procedures. In addition, some TCPIP products use the $ in filenames to do encoding of case changes or other special characters in NFS exports and mounted disks. -John wb8...@qsl.network Personal Opinion Only
