Test errors for 5.8.3
I just have built Perl 5.8.3 on OpenVMS Alpha 7.3-2. When running the tests, the vmsish test failed. lib/vars.ok lib/vmsish...FAILED at test 25 lib/warnings.ok The same build on OpenVMS VAX 7.3 failed 8 tests. PYTHON search build.log failed t/op/packFAILED at test 0 t/op/statFAILED at test 75 lib/ExtUtils/t/basic.FAILED at test 26 lib/ExtUtils/t/Constant..FAILED at test 23 lib/Math/BigInt/t/bare_mbi...FAILED at test 2600 lib/Math/BigInt/t/bigintpm...FAILED at test 2600 lib/Math/BigInt/t/sub_mbiFAILED at test 2600 lib/vmsish...FAILED at test 22 Failed 8 test scripts out of 760, 98.95% okay. -John [EMAIL PROTECTED] Personal Opinion Only
Test errors for 5.8.3
I just have built Perl 5.8.3 on OpenVMS Alpha 7.3-2. When running the tests, the vmsish test failed. lib/vars.ok lib/vmsish...FAILED at test 25 lib/warnings.ok The same build on OpenVMS VAX 7.3 failed 8 tests. PYTHON search build.log failed t/op/packFAILED at test 0 t/op/statFAILED at test 75 lib/ExtUtils/t/basic.FAILED at test 26 lib/ExtUtils/t/Constant..FAILED at test 23 lib/Math/BigInt/t/bare_mbi...FAILED at test 2600 lib/Math/BigInt/t/bigintpm...FAILED at test 2600 lib/Math/BigInt/t/sub_mbiFAILED at test 2600 lib/vmsish...FAILED at test 22 Failed 8 test scripts out of 760, 98.95% okay. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Test errors for 5.8.3
Craig A. Berry wrote: At 9:14 PM -0400 4/4/04, John E. Malmberg wrote: I just have built Perl 5.8.3 on OpenVMS Alpha 7.3-2. When running the tests, the vmsish test failed. lib/vmsish...FAILED at test 25 That was patched here: http://public.activestate.com/cgi-bin/perlbrowse?patch=3 Patch applied, and the Alpha tests restarted. They took 51 minutes on a 600 Mhz. All tests pass now on Alpha. The same build on OpenVMS VAX 7.3 failed 8 tests. PYTHON search build.log failed t/op/packFAILED at test 0 Hmm. That would be good to know about. What do you get from $ @[.vms]test .exe -v [.op]pack.t $ If F$Mode() .nes. INTERACTIVE Then Define/Nolog PERL_SKIP_TTY_TEST 1 $ MCR Sys$Disk:[]Perl. -I[-.lib] TEST. -v [.OP]PACK.T Improperly handled condition, image exit forced. Signal arguments Stack contents Number = 0003 Name = 04B400207785 0016C111 03C00007 0008 0001 022D2AEA 4080 Register dump R0 = 7FFF R1 = R2 = R3 = 7FFF R4 = R5 = 8000 R6 = 0001 R7 = 0008 R8 = 0009 R9 = 0043 R10= 00207784 R11= 0001 AP = 7FE9FDE0 FP = 7FE9FDA0 SP = 7FE9FE14 PC = 0016C111 PSL= 03C0 t/OP/PACKFAILED at test 0 Failed 1 test script out of 0, 0.00% okay. I guess I will need to do a debug build. That will probably take a while. PYTHON @local_root:[00]build_gnv_perl.com/out=build.log %DCL-E-OPENOUT, error opening _$1$DIA1:[00].DAT; as output -RMS-E-PRV, insufficient privilege or file protection violation Maybe a little longer. Now why is configure trying to put a file there? In trying to chase that down I get: Your PGFLQUOTA of 10 appears too small to build perl5. Now that looks interesting as the command file is supposed to allow that much. I fix that and still can not find the error, so am now running the procedure with out the output going to a log file, and now the build is running, probably well into tomorrow. t/op/statFAILED at test 75 This could be timezone setting related. lib/ExtUtils/t/basic.FAILED at test 26 lib/ExtUtils/t/Constant..FAILED at test 23 Dunno about these. There could be directory depth issues in the tests themselves. I thought ODS-2 on OpenVMS 7.3 allows deep directories on VAX. Well we look at this after I get a debug build. lib/Math/BigInt/t/bare_mbi...FAILED at test 2600 lib/Math/BigInt/t/bigintpm...FAILED at test 2600 lib/Math/BigInt/t/sub_mbiFAILED at test 2600 I think the BigInt module uses doubles to store chunks of very large integers. It probably makes some assumption that blows up on the very limited exponent range of D_FLOAT, which is still the default for Perl floating point on VAX. You could do a G_FLOAT build or hack into the innards of BigInt enough to see what it needs. The author has been very helpful sorting out similar situations in the past. Will look at that also. Looks like trying the G_FLOAT build for VAX might be the easiest thing to try. lib/vmsish...FAILED at test 22 Any chance you haven't reset the clock since the daylight savings change? Considering that the build started before the DST, and the tests probably did not finish until after DST, Yes. But if perl is using different rules than the system is, this could be a problem at other sites. At my former employer, the time change was delayed until the end of a shift. I hope this does not indicate a window where perl scripts could misbehave. Failed 8 test scripts out of 760, 98.95% okay. This has been better in recent memory. I don't have any vaxen and not many (any?) people who do are in the habit of building development releases on a regular basis and reporting or fixing the failures that show up. I will do what I can find time for. The VAX is idle and has nothing better to do, so after I get something working on Alpha, I copy it over the VAX. Now I also have to figure out how to set the [EMAIL PROTECTED] address subscribed to this list to a nomail setting. Now to start applying the BASH patches to the kit. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Test errors for 5.8.3
Craig A. Berry wrote: At 11:00 PM -0400 4/6/04, John E. Malmberg wrote: Assorted other issues snipped (I may get back to comment on them at some point, but no promises). No problems. If there is a discrepancy between your current offset from UTC and your timezone rule, then something that is explicitly testing that the two are in synch may run into problems. Anything that uses UTC or offsets from it (in short, anything using the standard C library functions) would have the same problem during the window between the time change and the system clock being reset. The actual problem is that there are multiple independent ways of specifying the offset from the local time to UTC on OpenVMS for historical reasons. I had a conversation with the editor of the OpenVMS FAQ about this today, and there will likely be an update to at least the OpenVMS FAQ. The bottom line is to prevent problems, if you are not changing to/from DST at the exact time that the timezone rule states, you need to use the ZIC utility to create a new timezone. And this was not obvious to me before this incident, and I am sure based on my conversation with the FAQ editor that I am not the only one to miss this. :-) -John [EMAIL PROTECTED] Personal Opinion Only
configure -s option incompatible with /output=log.file
It appears that the configure -s option is incompatible with having the
configure script being run from a wrapper command file with the output
redirected to a log file.
Removing the -s option results in prompts to continue.
For example for a command file:
$!
$if f$search(''build_disk'[''root']config.h) .eqs.
$then
$show time
$ @'build_disk'['root']configure.com -de
$! @build_root:['root']configure.com -Dusevmsdebug -de
$show time
$endif
EAGLE @LOCAL_ROOT:[00]build_gnv_perl.com/out=build.log
Type carriage return to continue
Type carriage return to continue
Type carriage return to continue
-John
[EMAIL PROTECTED]
Personal Opinion Only
Re: configure -s option incompatible with /output=log.file
Craig A. Berry wrote:
At 12:12 AM -0400 4/9/04, John E. Malmberg wrote:
It appears that the configure -s option is incompatible with having
the configure script being run from a wrapper command file with the
output redirected to a log file.
Removing the -s option results in prompts to continue.
For example for a command file:
$! $if f$search(''build_disk'[''root']config.h) .eqs.
$then
$show time
$ @'build_disk'['root']configure.com -de
$! @build_root:['root']configure.com -Dusevmsdebug -de
$show time
$endif
EAGLE @LOCAL_ROOT:[00]build_gnv_perl.com/out=build.log
Type carriage return to continue
[return pressed]
Type carriage return to continue
[return pressed]
Type carriage return to continue
[return pressed]
These are done with READ/PROMPT. What happens if you do DEFINE
SYS$COMMAND SYS$INPUT before running?
No change in behavior. I will look into this later.
From your description, if I submit this procedure to batch, it will
probably work ok.
-John
[EMAIL PROTECTED]
Personal Opinion Only
GNV BASH hacks on 5.8.4-RCI issues.
To bring this list up to date, Craig Berry and I have been discussing patches needed to use Perl to build the GTK+ package as part of Mozilla. I was giving a set of patches that were used for the last build, and Craig has also given me a patch that addressed some more issues. I have since found that the GNV BASH does not apparently modify the DECC feature logicals, so any issues with them and Perl are externally introduced. The essential issue is that if the following logical names are defined, Perl needs to behave slightly differently than it does now. * Case needs to be preserved. Currently Perl always lowercases filenames if any mixed case is found. I had one unconditional patch to do this well enough for a custom version of Perl to work. Craig Berry has provided a run-time conditional patch for some other points. I am doing a build with the two features merged. Craig points out that if Perl becomes unconditionally case preserving, it breaks the build of it self. So this should be noted as a build condition. As I understand it, neither Craig or I know if that catches all the instances where Perl is forcing things to lower case. * All input filespecs need to be interpreted as UNIX format This implies that . needs to be interpreted as the current directory. So far I have not found anything to suggest that any UNIX file names that could be mistaken for VMS filenames will be present. The patch seems to be two things. First to tread . as a UNIX filespecificaiton, and using the DECC$FEATURE to Perl disable the CRTL from from interpreting the feature setting that says to interpret all filenames as UNIX. The second is probably something that Perl needs anyway to prevent it from being externally victimized. It also appears a patch was also made to change the definition of BIT_BUCKET from _NLA0: to be /dev/null. It appears that this patch may not be needed, as the use in PERL is limited to a function that for modern versions of the CRTL treat them the same. As long as PERL does not follow any settings that force filenames to be treated as UNIX format. * Output file specifications need to be displayed in UNIX format. This is something that I do not have a conditional patch for. The Perl module CWD.PM needs to return the current path in UNIX format. * Apparently Perl must lie to the script so that the script thinks that it is running under UNIX. This is done in spec.pm I do not have a conditional patch for this one either. * The patch wants to use the CRTL unlink() function instead of kill_all. I do not know why. It also wants the unlink_all_versions defined. I have modified locally the configure.com procedure to allow specifying unlink_all_versions on a special build to do this. I would think it is better to have this as a run-time option so separate binaries were not needed. In doing this, I have discovered two things. 1. Gdiff on VMS can not handle it if it does not have write access to the files it is doing a diff on. It exists with an improperly signaled condition. 2. The contents of the config.sh file are mostly ignored. With the attached patches, the test phase of the perl build fails the following tests. lib/ExtUtils/t/basic.FAILED at test 28 lib/ExtUtils/t/zz_cleanup_dummy..FAILED at test 1 lib/File/Temp/t/tempfile.FAILED at test 14 Failed 3 test scripts out of 775, 99.61% okay. My guess is that it is a result of the unlink/unlink_all_versions issue. With the above tests, I have not patched the *.pm modules. The configure.com script was invoked with: $ @DIST_ROOT:[00]configure.com -Dunlink_all_versions -de If it is not obvious, I know almost nothing of perl or troubleshooting it, so any assistance to get a standard release of perl to be used for GTK+ would be useful. As far as I know, what I have now could be usable to build GTK+, but I would prefer to be able to pass all the standard tests with the Perl binaries produced. Thanks, -John [EMAIL PROTECTED] Personal Opinion Only --- dist_root:[00]configure.com Sun Apr 11 20:45:43 2004 +++ dist_root:[00]configure.com_old Sun Apr 11 21:58:27 2004 @@ -44,7 +44,6 @@ $ user_c_flags = $ use_ieee_math = y $ be_case_sensitive = n -$ unlink_all_versions = n $ use_vmsdebug_perl = n $ use64bitall = n $ use64bitint = n @@ -881,7 +880,7 @@ $ config_symbols1 =|installprivlib|installscript|installsitearch|installsitelib|most|oldarchlib|oldarchlibexp|osname|pager|perl_symbol|perl_verb| $ config_symbols2 =|prefix|privlib|privlibexp|scriptdir|sitearch|sitearchexp|sitebin|sitelib|sitelib_stem|sitelibexp|try_cxx|use64bitall|use64bitint| $ config_symbols3 =|usecasesensitive|usedefaulttypes|usedevel|useieee|useithreads|usemultiplicity|usemymalloc|usedebugging_perl|useperlio|usesecurelog| -$ config_symbols4 =|usethreads|usevmsdebug|usefaststdio|usemallocwrap|unlink_all_versions| +$ config_symbols4
Re: Case sensitivity and module names
IvorW wrote: There's an interesting issue with module names that has been raised on Perlmonks: http://perlmonks.org/index.pl?node_id=345472 A good article. There are actually a couple of ways that OpenVMS can work around this issue. With OpenVMS 7.3-1, On ODS-5 disks, and application can request case sensitivity in file lookups. So you could build Perl to live in a case preserved environment. Some other hacks for preserving case have been tried on VAX and Alpha, a common one is to use the reserved $ character to indicate a case change. With only 39 characters allowed in a file name, you quickly run into another barrier. One thing that might be useful is to adopt one of the schemes that used to be used with LINUX and other CDROMS to get around the 8.3 filename limitations, at least for directory that are read only or read mostly, like you would find for a build distribution. A special file was placed in each directory that mapped the short filenames to the expected filenames. The LINUX CD-ROM file systems knew to look in this file for the real file name. It should not be hard to write a procedure that generated such a file from a case preserved directory tree to be included in a tarball, ZIP archive or backup save set. And then used after a restore on an ODS-5 file system to make sure that the restored case was correct. A wrapper to the C file functions could be written that translate these names on the fly, which would allow such modules to be stored and built on an ODS-2 file system. Storing the UNIX exact case filename in a application specific ACE is also an option. For these options to be really effective some standard translation method would be needed for all applications. I am not sure that there is enough interest in all the people working on porting affected programs to be interested. Another option might be to look at storing .PM and .POD, and other such modules in text libraries. Then the wrappers to the C file functions will look in text libraries for modules instead of directories. The DECC compiler uses this for the header files. This may actually improve the performance of the Perl interpreter, and would also work on VAX. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Case sensitivity and module names
John Peacock wrote: Black, Andrew wrote: I would have thought the problem was more widespread than VMS, in particular Windows would be affected (at least as far as I can see). All windows versions I have come across regard File.pm file.pm FILE.pm as the same file. The NTFS file system considers them two separate files when read or written from the POSIX subsystem. Except that Win32 is case-preserving, but not case-sensitive. The POSIX subsystem is case sensitive. VMS downcases anything on the command line that isn't quoted. By default it upcases everything that is not quoted. It is the initialization sequence in C programs that downcases everything that is not quoted. With recent Alpha/IA64 versions, the behavior of DCL can be changed to preserve case with out quoting. It's a slightly different evil. Different things break under different circumstances. Win32 does have a full POSIX compatibility layer (it's called CygWin ;), but I don't think UNV rises to that leverl yet... GNV requires a lot of work, however ODS-5 with 7.3-1 and later will be case sensitive if desired. The options actually give programs like perl some issues as they need to check the environment to determine how they should operate. -John [EMAIL PROTECTED] Personal Opinion Only
Re: system long commands and stderr redirection.
Douglas B Rupp wrote: Very interesting. So gcc on VMS is under active development? Absolutely. My company is working on the IA64 VMS port of GNAT under contract to HP. GNAT as you may know, is the Gnu Ada compiler and Gnu C is required to build the backend. I don't really recommend Gnu C for serious development on VMS, since its not compatible with the standard DEC C header files. Only the ones needed for building GNAT and bootstrapping Gnu C have been ported. If such information can be made available publicly, One of the projects on my list is to build a GCC 6809 cross complier that runs on OpenVMS. The one that I currently have only works under cygwin. The latter version uses Perl. So far I've run into two problems with the Perl system function. One is stderr can't be redirected properly, Define properly. What do you want it to do and what does it do instead? For example this command: system $m4 --help /dev/null 21 | grep reload-state /dev/null; writes the help output to the screen, when it should be going to /dev/null. That may need to be handled by GNV, or HP C RTL folks as the redirection is being handled by m4, presumably a C program in GNV, not by the Perl system function. another is long command lines don't work. I suspect system is implemented with lib$spawn? Yes, system is implemented via lib$spawn, so as far as I know, there's no way around DCL command line limits. You can see the implementation in the Perl_do_spawn() function in [.vms]vms.c in the Perl sources. The line limits are increased in 8.2, do you have access to the pre-release code before the field test? You may want to contact HP to see if they can give you a backported DCL, if it is possible for it to run on an older version. I believe that a better solution would be for system to look at the program(s) being executed, and if they are CRTL based executables then vfork/exec should be used, otherwise falling back to lib$spawn. This is what my ports of bash and Gnu make do, and it works quite well. Are these separate from GNV? I used to have an anonymous ftp site and some of my Gnu tools for VMS made their way eventually to DEC-Compaq-HP and I think now reside on sourceforge.net. They cleaned up and rewrote the VMS specific piping in bash, and ended up breaking some things. I've sent them a few bug reports but I don't know if they ever got fixed. As far as I know, the current GNV is: 1.5-6. There is ongoing work on the make application and with pipes. I think that there is an e-mail contact for feedband on the GNV download page. I do not have time to look for it at the moment. You can join Encompasserve.org (free) and put files in the [.www] directory protected w:re, with the files protected also w:re and they will be available for download through a web server via: http://encompasserve.org/~username/ -John [EMAIL PROTECTED] Personal Opinion Only
Re: system long commands and stderr redirection.
Douglas B Rupp wrote: For example this command: system $m4 --help /dev/null 21 | grep reload-state /dev/null; writes the help output to the screen, when it should be going to /dev/null. That may need to be handled by GNV, or HP C RTL folks as the redirection is being handled by m4, presumably a C program in GNV, not by the Perl system function. I think that is wrong. The Perl system function should handle redirection that same on Unix as it does on VMS. I was able to work around the problem by rewriting the above as the following: While I do not know what the Perl system function is doing, it would look to me that it is simply passing the command through as a DCL command, and as such is not attempting to interpret the redirection codes at all. system bash -c \$m4 --help /dev/null 21 | grep reload-state /dev/null\; which demonstrates the problem doesn't need to be handled by m4. I will have to confess that I know little of bash, m4, or perl. However, it now appears that the redirection is being done by bash instead of md4 or dcl. The system function appears to assume that the underlying operation system will understand the quoted command, and makes no attempt to process it. The question is is if the command: m4 --help /dev/null 21 | grep reload-state /dev/null will work under DCL. The behavior seems to be explained in these comments in VMS.C. * Note on command arguments to perl 'exec' and 'system': When handled * in 'VMSish fashion' (i.e. not after a call to vfork) The args * are concatenated to form a DCL command string. If the first arg * begins with '$' (i.e. the perl script had \$ Type or some such), * the command string is handed off to DCL directly. Otherwise, * the first token of the command is taken as the filespec of an image * to run. The filespec is expanded using a default type of '.EXE' and * the process defaults for device, directory, etc., and if found, the resultant * filespec is invoked using the DCL verb 'MCR', and passed the rest of * the command string as parameters. This is perhaps a bit complicated, * but I hope it will form a happy medium between what VMS folks expect * from lib$spawn and what Unix folks expect from exec. So it appears one way to implement what you may need is a modification for Perl for VMS to use the BASH shell instead of DCL, or to run the program with out a shell at all. Maybe one of the Perl maintainers can figure out a patch. Perl can detect if it is running under bash and should use it instead DCL by looking at the environment variable SHELL to see if perl is being run under bash another is long command lines don't work. I suspect system is implemented with lib$spawn? Yes, system is implemented via lib$spawn, so as far as I know, there's no way around DCL command line limits. You can see the implementation in the Perl_do_spawn() function in [.vms]vms.c in the Perl sources. The line limits are increased in 8.2, do you have access to the pre-release code before the field test? I think that is also wrong. The method I described handles virtually unlimited command line lengths. Unless the DCL command line length liimit has been completely removed (which I find very unlikely but maybe worth asking about), it won't be enough for other than trivial scripts. The DCL line length has not been completely removed. And i was in error. The new line lengths are in 7.3-2. A line can now be 4095 bytes in length. Perl has an internal limit of (4*MAX_DCL_SYMBOL-4) for the line lengths and since MAX_DCL_SYMBOL is 255, this limits it to 1016 characters. With VMS 7.3-2 and later on Alpha/IA64 DCL symbols are limited to 8192 bytes, and previously they are limited to 1024 bytes. As I do not know the history of the perl limitations, I do not know what would have to be changed to have them take advantage of the new size. -John [EMAIL PROTECTED] Personal Opinion Only
Re: system long commands and stderr redirection.
Craig A. Berry wrote: The way I see the problem is that we are running the command under the wrong shell (DCL instead of bash). One possibility here would be to have Perl detect whether it is running under bash and if it is, then prepend bash to the command for system(), exec(), and backtick operations. That would be looking at the environment variable SHELL and using it's value if it is present. If it is not present, fall back to the current behavior. Better yet, if there were some way to make bash a true-blue CLI from a VMS standpoint, then lib$spawn would automatically use whatever CLI is in use by the parent. That's out of my league and I have no idea how possible or difficult that would be. I do not know either. I do not think that making it a true CLI is high on the current priority lists. Bash currently uses DCL in a fallback mode, and so it would have to be able to detect if DCL was not there. It may already be able to do that. -John [EMAIL PROTECTED] Personal Opinion Only
Re: GNV BASH hacks on 5.8.4-RCI issues.
Craig A. Berry wrote:
At 2:58 PM -0400 4/25/04, John E. Malmberg wrote:
Indeed. So Perl is able to build itself and all the core extensions
with your modifications?
It seems so. The intent was that unless the C features were enabled,
that they would not be visible.
I do not have any feature logicals set for the build. They might affect
things, and then the build procedure would have to disable them to
protect it self.
--- dist_root:[00]configure.com_old Sun Apr 11 21:58:27 2004
+++ dist_root:[00]configure.com Sat Apr 24 22:31:30 2004
Forgive the ongoing nitpicking of your patch style, but unless these
filespecs are in unix syntax, folks who have check-in authority are
not going to be able to apply it. I know you may not intend the
patch to be ready for that yet, but it's getting darn close.
I will have to use the bash shell to change the syntax. The samba/rsync
folks seem to be able to accept them. Having never run a patch
procedure, I do not know if it cares about what is in the filename, but
just uses it as a comment. After all, those lines do not contain
anything that the patch program needs to apply the patch.
Lots of stuff that looks ok snipped.
@@ -4384,8 +4422,10 @@
* the argv items and lowercase all of these names.
*/
for (c = string; *c; ++c)
+ if (!decc_efs_case_preserve) {
if (isupper(*c))
*c = tolower(*c);
+ }
if (isunix) trim_unixpath(string,item,1);
add_item(head, tail, string, count);
++expcount;
I would think we'd want to check decc_efs_case_preserve outside the loop.
So do I. I am surprised that I did not see that before. My suspicion
is that I put the line in the wrong place. I will change that even
though the compiler should know to do the right thing.
more good stuff snipped.
+s = decc$feature_get_index(DECC$FILENAME_UNIX_REPORT);
+decc_filename_unix_report = decc$feature_get_value(s, 1);
+set_feature_default(DECC$FILENAME_UNIX_REPORT, FALSE);
+
+s = decc$feature_get_index(DECC$FILENAME_UNIX_ONLY);
+decc_filename_unix_only = decc$feature_get_value(s, 1);
+set_feature_default(DECC$FILENAME_UNIX_ONLY, FALSE);
But I'm confused on these two. It looks to me like we check for
whether the features are enabled and save the setting we inherited
from the environment, but then we also explicitly disable the
features. If we honor the values we inherit, it seems we would not
want to disable them. If we disable them, it seems we would not want
to save the values we inherit. What am I missing?
If you leave these features set, it may cause problems when filenames
are passed from C routines to RMS or system services.
It may also have other side effects for filenames that are externally
displayed, which is probably desired.
To leave these features enabled would require more study of the code to
make sure that there are not any problems, and probably some more tests.
But the settings are remembered so that perl will treat . as UNIX
./, instead of SYS$DISK:[].;
+}
+status = sys_trnlnm(DECC$FILENAME_UNIX_ONLY, val_str, sizeof(val_str));
+if (status) {
+ _toupper(str[0])
+ if ((str[0] == 'E') || (str[0] == 1) || (str[0] == 'T')) {
+ decc_filename_unix_only = 1;
+ status = sys_crelnm(DECC$FILENAME_UNIX_ONLY, ENABLE);
+ }
+}
Hmm. On this last one we are checking to see if it's already enabled and then re-enabling it?
That is a bug, Since this is a newer version than the #ifdef, it should
not be affecting what I built.
This code was copied from what I did on Python where it was desired to
have all internal filenames in UNIX format.
+
+/* CRTL can be initialized past this point, but not before. */
+/*DECC$CRTL_INIT(); */
A side note here.
Putting a DECC$CRTL_INIT() in a lib$initialize psect may have undesired
effects if put in a shared image. They get chained, and if a C program
is linked with a shared image that has such a call, it will prevent the
features from being detected. This was discovered with Python, and the
RDB module had to be converted to being dynamically loaded to fix.
So there are two psects, LIB$INITIALIZ and LIB$INITIALIZE ?
Yes. I suspect that the LIB$INITIALIZ psect name is not critical, since
the documentation is a bit sparse on that, I would have to either
rummage around in the internals, or track down who ever is currently
maintaining that code.
Well, now I will see if I can find out why that one test is failing, and
then I will look at the two .pm scripts that I am told need a change to
build GTK+.
When I actually try to build GTK+, I may find more issues.
-John
Re: GNV BASH hacks on 5.8.4-RCI issues.
Craig A. Berry wrote:
Read the instructions in README.vms :-).
. where it will tell you
$ @[.vms]test .exe -v [-.lib.extutils.t]basic.t
though the second argument should be ndbg instead of empty if
you've got a VMS debug build.
The test failed with a file not found error, so I tried to run the 'mcr
[]miniperl -V' command.
It turns out that somehow while the when Perl was running the tests
under MMS, it knew the value of Perl_root correctly, it did not have a
correct definition in Perl_setup.com.
It had EAGLE$DQA0:[PROJECT_ROOT.PERL.PERL-5_8_4-RC1_ROOT.] when the
files were really in EAGLE$DQA0:[PROJECT_ROOT.PERL.PERL-5_8_4-RC1.].
This looks like the proper print out for -V, however the test driver
is still not finding the file.
Ok, now I understand the meaning that the test path names must be
relative to the [.t]directory.
Something is still wrong as now the test fails at 1 for doing a chdir(),
where when run from the MMS script, it does not fail until test 28.
Ok, found it. The LIB tests are not standalone.
You must run 00setup_dummy before running basic, and after running
basic, apparently run zz_cleanup_dummy to clean up the directories.
Now running the basic.t test interactively worked, so I do not know why
it did not from an MMS interactive process.
ok 27 - install
ok 28
ok 29
ok 30 - install dir created
So I still do not know what those two steps are or if my patch had
anything to do with the test failure when it was run from MMS.
Looking now at the cwd.pm, I see that the better fix could be to change
vms.c to return $ENV{'DEFAULT'} in UNIX syntax when desired. This
appears to be a simple change to VMS.C.
In reviewing the spec.pm module, it appears that it selects the method
that will be used for doing operations on the file. Apparently with the
'VMS' line commented out, it defaults to 'UNIX'.
It is not as I originally thought something that reports an operating
environment of UNIX.
So while spec.pm could get a simple hack to fix, the proper fix would be
to have [lib.file.spec]vms.pm to behave as it had received UNIX
filenames if one of the DECC$FILENAME_UNIX_ONLY or
DECC$FILENAME_UNIX_REPORT logical names is set. This may be the same
module that needs to be changed to deal with ^ escaped filenames, and
with filenames that are in File ID Format.
Such a change to [lib.file.spec]vms.pm is probably beyond my ability at
this point
Even a hack to spec.pm to be conditional in it's behavior appears to be
beyond my present non-existent perl programming abilities.
So if tonight's build works, I will be using a locally customized
spec.pm and moving on to attempt to build the next components of Mozilla.
Before I could send this, I discovered that the build worked, and this
time all tests passed. However, I forgot to fix the problem Craig
identified where I had a test inside of a loop that should be outside of
it on the case preservation, so I am running the build and tests again.
I should have some diffs tomorrow evening.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Re: Perl 5.8.4-RC1 debug build on OpenVMS 7.3 VAX
John E. Malmberg wrote: A Debug build and test of Perl 5.8.4 RC1 on OpenVMS VAX 7.3 has produced the following information: PYTHON dir [...]*.*;/size/grand Grand total of 452 directories, 5179 files, 604207 blocks. The bulk of the original message apparently got truncated by Mozilla. Apparently when it runs out of resources, things slowly stop working. I had thought I had sent the rest of it again, but now can not find the original message at all. Failed 225 test scripts out of 625, 64.00% ok I am starting to look at the failures. The first test to fail is switchpx.t. This is testing the -P and -x flags. The Perl documentation, states that the -P switch uses the C preprocessor, and is a portability problem. The -x finds a perl script in a file and runs it. This is probably something different between the DEC C compiler for VAX and for Alpha. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Perl 5.8.4-RC1 debug build on OpenVMS 7.3 VAX
John E. Malmberg wrote: Failed 225 test scripts out of 625, 64.00% ok I am starting to look at the failures. A spot check of the majority of the failures seem to be about handling multi-byte character sets, particularly the Japanese set. -John [EMAIL PROTECTED] Personal Opinion Only
Re: GNV BASH hacks on 5.8.4-RCI issues.
Here are the gdiff files for the changes that I have made that should allow the DECC feature logicals to modify perl's behavior to build GTK+. It still will probably need a modified spec.pm. With these changes, and then built with: $ @'build_disk'['root']configure.com -Dunlink_all_versions -de The resulting perl on 7.3-2 will pass all tests without any DECC feature logicals set. As I stated, I do not think I am up to modifying the perl scripts to make them follow the intent of the DECC feature logicals. The next test will be building GTK+ -John [EMAIL PROTECTED] Personal Opinion Only --- configure.com_old Sun Apr 11 21:58:27 2004 +++ configure.com Sat Apr 24 22:31:30 2004 @@ -44,6 +44,7 @@ $ user_c_flags = $ use_ieee_math = y $ be_case_sensitive = n +$ unlink_all_versions = n $ use_vmsdebug_perl = n $ use64bitall = n $ use64bitint = n @@ -880,7 +881,7 @@ $ config_symbols1 =|installprivlib|installscript|installsitearch|installsitelib|most|oldarchlib|oldarchlibexp|osname|pager|perl_symbol|perl_verb| $ config_symbols2 =|prefix|privlib|privlibexp|scriptdir|sitearch|sitearchexp|sitebin|sitelib|sitelib_stem|sitelibexp|try_cxx|use64bitall|use64bitint| $ config_symbols3 =|usecasesensitive|usedefaulttypes|usedevel|useieee|useithreads|usemultiplicity|usemymalloc|usedebugging_perl|useperlio|usesecurelog| -$ config_symbols4 =|usethreads|usevmsdebug|usefaststdio|usemallocwrap| +$ config_symbols4 =|usethreads|usevmsdebug|usefaststdio|usemallocwrap|unlink_all_versions| $! $ open/read CONFIG 'config_sh' $ rd_conf_loop: @@ -2442,6 +2443,27 @@ $ use_ieee_math = n $ ENDIF $ useieee = undef +$! Unlink all versions? +$ echo +$ echo By default apparently Perl will only unlink (delete) the latest +$ echo version of a file. This option builds PERL to delete all versions +$ echo of a file +$ echo +$ echo If you have no idea what this means, and do not have +$ echo any program requiring anything, choose the default. +$ bool_dflt = unlink_all_versions +$ if f$type(unlink_all_versions) .nes. +$ then +$ if unlink_all_versions .or. unlink_all_versions .eqs. define +$ then +$ bool_dflt=y +$ else +$ bool_dflt=n +$ endif +$ endif +$ rp = Build with unlink_all_versions? [''bool_dflt'] +$ GOSUB myread +$ unlink_all_versions = ans $ usecasesensitive = undef $ if (use_ieee_math) then useieee = define $ if (be_case_sensitive) then usecasesensitive = define @@ -2912,6 +2934,12 @@ $ ELSE $ d_vms_be_case_sensitive = undef $ ENDIF +$ IF unlink_all_versions +$ THEN +$ d_unlink_all_versions = define +$ ELSE +$ d_unlink_all_versions = undef +$ ENDIF $! Some constant defaults. $ hwname = f$getsyi(HW_NAME) $ myname = myhostname @@ -6154,6 +6182,7 @@ $ IF use64bitall .OR. use64bitall .EQS. define THEN - WC #define USE_64_BIT_ALL $ IF be_case_sensitive THEN WC #define VMS_WE_ARE_CASE_SENSITIVE +$ IF d_unlink_all_versions then wc #define UNLINK_ALL_VERSIONS $ IF d_herrno .EQS. undef THEN WC #define NEED_AN_H_ERRNO $ WC #define HAS_ENVGETENV $ WC #define PERL_EXTERNAL_GLOB @@ -6165,6 +6194,10 @@ $! WC #define PERL_IGNORE_FPUSIG SIGFPE $ ENDIF $ IF kill_by_sigprc .EQS. define then WC #define KILL_BY_SIGPRC +$ if unlink_all_versions +$ then +$ WC #define unlink_all_versions +$ endif $ CLOSE CONFIG $! $ echo4 Doing variable substitutions on .SH files... --- vms/vmsish.h_oldSun Apr 11 21:55:17 2004 +++ vms/vmsish.hSat Apr 24 23:14:49 2004 @@ -2,6 +2,7 @@ * * VMS-specific C header file for perl5. * + * Hacks by J. Malmberg for testing. * Last revised: 16-Sep-1998 by Charles Bailey [EMAIL PROTECTED] * Version: 5.5.2 */ @@ -214,7 +215,14 @@ #define init_os_extras Perl_init_os_extras /* Delete if at all possible, changing protections if necessary. */ +#ifndef UNLINK_ALL_VERSIONS #define unlink kill_file +#else +#if __CRTL_VER 7000 +/* No unlink this early */ +#define unlink kill_file +#endif +#endif /* * Intercept calls to fork, so we know whether subsequent calls to @@ -330,7 +338,11 @@ #define PERL_SOCK_SYSWRITE_IS_SEND #endif +#if __CRTL_VER 7000 #define BIT_BUCKET _NLA0: +#else +#define BIT_BUCKET /dev/null +#endif #define PERL_SYS_INIT(c,v) MALLOC_CHECK_TAINT2(*c,*v) vms_image_init((c),(v)); MALLOC_INIT #define PERL_SYS_TERM()OP_REFCNT_TERM; MALLOC_TERM #define dXSUB_SYS --- vms/vms.c_old Sun Apr 11 21:54:18 2004 +++ vms/vms.c Sun May 9 23:31:18 2004 @@ -3,6 +3,8 @@ * VMS-specific routines for perl5 * Version: 5.7.0 * + * April 2004 Add LIB$INITIALIZE section so DECC feature logicals will + *not change behavior unintentionally. * August 2000 tweaks to vms_image_init, my_flush, my_fwrite, cando_by_name, * and Perl_cando by Craig Berry * 29-Aug-2000 Charles Lane's piping improvements rolled in @@ -42,6 +44,13 @@ #include uaidef.h #include uicdef.h +#if __CRTL_VER 70301000
Re: JAVA$FORK_PIPE_STYLE = 2 : can we steal it?
Craig A. Berry wrote: However, there is no indication of how or in what layer this is done. Is this something in C that is a drop-in replacement for the CRTL's popen and friends? Or is it in pure Java? Either way, does anyone here know more about how it's done and/or have an opinion about whether this model could be applied elsewhere, say, in Perl ;-). I do not know what JAVA is doing, but what may fit your requirements is something known as socketpair(). There is an open source implementation for it in the SAMBA test code, and in RSYNC. I also expect that socketpair() will be available with OpenVMS 8.2, but do not consider this a commitment on that. socketpair() also helps when simulating fork() by use of POSIX threads. -John [EMAIL PROTECTED] Personal Opinion Only
Re: performance, compilation, Spamassassin (was Re: Wishlist remarks)
Craig A. Berry wrote: At 12:19 AM -0400 6/7/04, John Malmberg wrote: Craig A. Berry wrote: To compile Perl directly, you need to interface to a back end code generator. True, but we need to define code here. For Perl, it generally means bytecode that is run on the Perl bytecode engine, which is roughly equivalent to what Java folks call a virtual machine. I say roughly because Perl is a dynamically typed language (unlike Java or C#). In Perl, 8.341 may just be a string right up until the point you do arithmetic on it, at which point it becomes a number. Several other compilers know how to deal with that. All variables are passed by descriptor to most routines. Others can be handled by the optimizer. An example in the C compiler is the handling of printf, sprintf, fprintf. If the optimizer can resolve the format string at compile time, it breaks up the call into more specific formatting routines. The Gnat ADA project uses the code generator in GCC for this, and if the other Perl compilers use this, then there may be a way to get this done on OpenVMS. Good point. If someone were to target the GCC code generator, and if this code generator were sufficiently smart enough to generate the right instructions on Alpha and Itanium (no small task), then there's no particular reason this wouldn't work as well on VMS as elsewhere. GCC has code generates for almost every processor, including VAX, Alpha, and IA64. As far as your other points, I am totally ignorant of Perl and what the compiler efforts are doing. Generally the way that a code generator works is that it provides an API to describe the instruction set to the front end of the compiler so that the front end can emit the proper code stream. Logically if an open source project like Perl is going to have a version that can be compiled to an executable, it would either have a custom code generator that will only support a few targets, or it would use the GCC code generator. Using the GCC code generator is not a trivial project. The GCC documentation appears to be several generations behind the current code base. -John [EMAIL PROTECTED] Personal Opinion Only
Re: New member, and a newer patch for File::Spec::VMS
Richard Levitte - VMS Whacker wrote: Hmm, I found a small bug. A file spec. []FOO wasn't reduced to FOO by my changes. The attached patch contains one more line that takes care of that particular thing. I'm going through the rest of File::Spec::VMS right now, finding more things that aren't at all consistent with proper directory mangling on VMS. There will be more patches, one for each function I correct... While you are in the area, I submitted a patch to 5.8.4 release candidate that gets Perl to almost honor the C feature logicals. This is apparently needed to build the version of GTK+ that is used for Mozilla. To make the patch complete, the File::Spec::VMS needs to also be modified to look at what the C feature logicals were before Perl started, and and if they were the set to (IIRC) DECC$FILENAME_UNIX_ONLY or DECC$FILENAME_REPORT_UNIX, do the parse like it was UNIX, and display the filespec as if it were UNIX. I do not know enough about Perl programming to make those changes myself. -John [EMAIL PROTECTED] Personal Opinion Only
Re: New member, and a newer patch for File::Spec::VMS
Richard Levitte - VMS Whacker wrote: In message [EMAIL PROTECTED] on Thu, 22 Jul 2004 20:38:49 -0400, John E. Malmberg [EMAIL PROTECTED] said: I've yet to be able to build 5.8.4 on my VAX (VMS 7.2, DEC C 6.2-003, anyone been able to build on that combination?), but I'll try it out on the Alphas I have access to when I got a little more time. DEC C V6.4-005 is the current C compiler. Perl 5.8.4 will build on VAX 7.3, but IIRC will only pass about 68% of the tests. It looks like a lot of the problems are in multi-byte character support. wb8tyw I do not know enough about Perl programming to make those wb8tyw changes myself. Hmm, if I'm gonna get involved at a deeper level, it will take some monetary contribution. I currently live on bare minimums (the consulting business is harsch right now), so I only spend time on my needs... I have a work-a-round, a hacked version of a different .pm file and changing a logical name for the perl libraries to find it before it finds the Perl ones. My main motivation is that I am trying to find time to build Mozilla from sources, and discovered that a hacked version of Perl was previously needed. I have not yet had time to try to build GTK+ with Perl 5.8.4. I have also started working again on getting rsync to run on OpenVMS. It requires replacing a few fork()ing things with some threads. At this point I have a barely functional client that can pull down the daily rsync updates. Cheers, Richard - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. Hope the consulting business picks up over there. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Test failiure 5.8.5 final
Craig Berry wrote: On Monday, July 26, 2004, at 03:15PM, Dr. Martin P.J. Zinser [EMAIL PROTECTED] wrote: I've got one failiure during mmk test: t/uni/class...FAILED at test 2959 Yeah, I knew about this, but didn't (and still haven't) gotten around to doing anything about it yet. The test does a directory scan to collect a set of unicode class names to test for. It assumes case preservation when doing readdir(), which will never work on ODS-2. It currently does not work on ODS-5 either because Perl follows the old CRTL practice of downcasing filenames. If the patch that I submitted for 5.8.4 Release Candidate has been incorporated, IIRC, setting the appropriate DECC feature logical will cause case to be preserved. -John [EMAIL PROTECTED] Personal Opinion Only
Re: GCC on OpenVMS
Craig Berry wrote: Having said all this, I would be happy to see an up-to-date and useable GCC port on OpenVMS just for the niftiness factor if nothing else. It might bring with it some other capabilities, like Objective C, that are otherwise unavailable. But given the lack of a business case, it would require a serious (*really* serious) volunteer effort. One thing that it would bring is the ability to cross compile for other targets, such as small standalone microprocessors such as the 6809. Some information was posted on comp.os.vms today about GCC on VMS by Simon Clubley. -John [EMAIL PROTECTED] Personal Opinion Only
Re: GCC on OpenVMS
Henderson, Jordan (Contractor) (DAASC) wrote: HP might have a need to have this supported. A case could certainly be made to have Gnu C/C++ available for the OpenVMS platform to enhance the viability of the platform, I would think. It can get a bit more interesting, as OpenVMS on Itanium uses ELF files for objects and executables. There have been some extensions that have been provided. So there may be a possibility of building VMS binaries including executables, objects, and shared images on other IA64 systems. Or the reverse. The problem with volunteers maintaining GCC on OpenVMS is that the HP C compilers are free for hobbyists so there is little incentive for anyone to work on it. I don't have a clue how to go about making this case to HP, however. They're already doing a lot of kind of work with Apache, PHP, Java... so, it might be hard to get their attention. The issue with open source is the funding of the people that work on it. The business case to HP would have to show enough revenue and profits to cover the salaries of anyone working on it. Would enough people be willing to purchase a support contract to cover ongoing maintenance? In some cases it may be more of an opportunity for a third party to sell support services and become a DSPP partner. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Correct way to delete file(s) on OpenVMS?
Craig A. Berry wrote: There's also a configure-time option in Perl to delete all versions of a file, but it's currently not working. John Malmberg submitted a patch that makes it work, but I'm afraid I have sat on it for a while, though I have not forgotten it and hope to get to it soon. IIRC: As part of that patch, it allows a configure time option to use unlink() instead of remove(). What unlink() does is removes a link to a file, and if it is removing the last link to a file, the file is deleted. With remove(), the file is removed, and the links become orphaned if I understand the UNIX specifications correctly. That is why unlink() may be preferred to remove(). With upcoming versions of OpenVMS, that could be a significant difference in behavior. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Correct way to delete file(s) on OpenVMS?
Craig Berry wrote: There is now one of the DECC$* logicals that specifies whether or not a version number is allowed in unix syntax file specifications passed to the CRTL, but that's not pertinent here. There is a configure-time option to Perl that is not (quite yet) implemented that will cause a single unlink call to delete all versions. The feature logical does not affect the handling of existing files, so if there are already other versions of the file, the effect may not be what you want. Also, there seems to be an issue currently with the rename() if there is already an existing file, a new version gets created regardless of the feature setting. -John [EMAIL PROTECTED] Personal Opinion Only
GCC / HP C (- was: Correct way to delete file(s) on OpenVMS?)
Mark Berryman wrote: My own experience disagrees with the assessment given in the 1st quoted message. While it is true that the DECC compiler generates better code than the GNU C compiler (this is evident even on Linux), there are a number of features in the GNU C compiler that do not exist in the HP supported compiler and there are some packages that make heavy use of these features. Case in point would be the __attribute__ modifer which provides functionality for which there is no duplicate in DECC (other than manual work by the programmer). For the packages I've worked on, I've never needed the Unix syntax (the only one that has been an issue is the fact that -I can be specified multiple times but /INCLUDE_DIRECTORY can only be specified once and I've always been able to solve that) but it has been a royal pain to find ways to address the differences in functionality. A functioning recent version of GCC for VMS would make this work much easier. If there are specific features of GCC that are missing from HP C that would aid in porting programs, the compiler team seems to be interested in them, and may be able to implement them as an option in future compilers. For example the /ACCEPT=GCCINLINE qualifier. The __attribute__ modifier corresponds to the #pragma directives in the C compiler, however while both are non-portable, IMHO the __attribute__ modifier is easier to read. -John [EMAIL PROTECTED] Personal Opinion Only
Re: [PATCH] -Dunlink_all_versions for VMS
[Only sent to [EMAIL PROTECTED] Craig A. Berry wrote: There has for some time been latent support in the Perl sources to make unlink() delete all versions of a file on versioning file systems when Perl has been configured to do so. It is rather odd given the fact that we say we have this capability in perlvms.pod -- and even odder given the fact that VMS is quite likely the only supported platform that could make use of the feature -- that the configure-time work to support this has never been done. The attached patch corrects this deficiency. I still feel that this should be a run-time option rather than a compile time option. Otherwise someone may need to keep two copies of Perl around. Thanks to John Malmberg for noticing this was missing and submitting a patch to vmsperl. Mine looks a lot like his but doesn't change the C sources since the support that was already there works fine; we just needed configure.com to do its part. I would have to look to see why I changed the C sources, I was working from Collin Blake's patches for an earlier perl release. The only other possibility is that it was for better handling of UNIX filenames, but even that does not sound right. -John [EMAIL PROTECTED] Personal Opinion Only
Re: GCC on OpenVMS
Willem Grooters wrote: I would like to add the shops that use VMS-native compilers (Fortran, Cobol, Pascal, etc). If GCC delivers a non-VMS object format, it is of no use at all. Even if it did - what would be the benefit (except the cost)? GCC delivers a VMS object format. With IA64, OpenVMS uses close to the same ELF format that LINUX and other platforms use. Some extensions have been added to support VMS specific features, and those extensions have been fed back to Intel for eventual inclusion in the specification. This brings a possibility of being able to compile and link images for another IA64 operating system, even though that is not something that was specifically tested. A Unix-like interface would indeed be handy - but the GNV CC-wrapper does just that, if I'm informed well. Take a look at http://www.4ovms.dyndns.org/phpbb/viewtopic.php?t=17 for an overview. But not a unix-style one in stead of a VMS-style one, and a decent HELP specification. That rules GCC out - for the moment. The last GCC implementations for VMS that I saw had a VMS style CLD on them. Unfortunately who ever produced the last binary for them seems to have misplaced the source. I do not know if anyone has recreated the missing source for the wrapper code. If my faulty memory is correct, there was also a VMS help file for this. That VAX is powered off at the moment to conserve power. In my rsync tests on http://eisner.encompasserve.org/~malmberg/rsync/ there are tpu routines that will attempt to convert a UNIX man page in to .RNO or .RNH file, and the .MMS file should show how to convert them into a .HLB. It still does not handle every syntax found, but it will do the bulk of the conversion, and can usually be tweaked for the rest. The compiler is one thing. What about: * exception ahndling (status, messages...) * RECORD-based IO in stead of STREAM-IO * Naming conventions. GCC on VMS uses the existing DECC$SHR routines for most of it's runtime, so the compiler does not even have to deal with those issues. On VAX, use the NO PREFIX library for linking with the DECC$SHR. One issue is that GCC for VMS when last seen could not use the .TLB files containing the C headers which are now supplied with VMS. The two problems are that it can not read the .TLB files, and that the header files are written to expect a HP C compiler. These are more important issues than just the compiler. You can port a program so it runs, but if it cannot co-operate with natively built programs properly, the effort is useless. One of the big attractions for GCC is that it provides a back end code generator for other programming languages or for cross compiling. Languages that use GCC do not convert to C first, and then compile, their front ends call a back end to get specific code patterns to generate. The resulting code is then fed to to the GNU Assembler. Unfortunately while that back end code generator is open source, the documentation on how to use it is several generations out of date. -John [EMAIL PROTECTED] Personal Opinion Only
Re: [PATCH] Re: getting Config.pm on a diet
Note: I think I only get mail on the [EMAIL PROTECTED] list. Nicholas Clark wrote: On Mon, Nov 29, 2004 at 01:58:52PM -0600, Craig Berry wrote: I'm not sure. I was trying to keep Config's AUTOLOAD as simple as possible. Then again, using %INC shouldn't be that hard. For the Unix Makefile I hit the same problem (with the POD scripts) and the solution I found was to change the -I on the command line from a relative to an absolute path. Is that viable with the VMS MMS file? Or have I missed some VMS specific subtilty? A VMS specific method would be to have a logical name that equated to a search list. $define foobar foo:[dir1],bar:[dir2] You can have quite a few directories on the list, and they would show up in UNIX syntax as all being in the same directory: foobar/x.h My preference in doing VMS builds of application is to use the search list feature of logical names to isolate the source from the resulting binaries and intermediate files. For example: Dist_root:[*...] is a source directory tree that the build procedure does not have privilege to modify. local_root:[*...] is the directory with locally modified source files for testing patches, etc. DEFINE BUILD_ROOT local_root:,dist_root: Set default BUILD_ROOT:[00] ! Or other base directory. Now VMS will automatically look in the local_root: directory tree first for a file, and if it is not found, will look in dist_root: directory tree. New files being created will be put in the LOCAL_ROOT: tree. This does not work if the build procedure is expecting to actually modify files from the original distribution in place. Perl at the last time I attempted a build on VMS could not use such a search list. FYI: It looks like building SAMBA Version 4 on VMS will require using PERL to do the configuration phase. -John [EMAIL PROTECTED] Personal Opinion Only
Re: MMK manual wanted
Michael G Schwern wrote: Thank you all. Now I have the set. I've posted them up here so I don't lose them again. http://www.makemaker.org/make_docs/ Unless you get written permission from HP to serve a copy of their documentation, you are in violation of their copyright. I would recommend just posting a link to http://www.hp.com/go/openvms/doc/ and removing the link to the copy on your server. The /h*.www*.hp.com/ style URLs are subject to change with out notice. -John [EMAIL PROTECTED] Personal Opinion Only
Needs console help for unknown ALPHA system (Was: Setup)
Carlos Elias Alves wrote: Hello, my name Carlos. I´m from Brazil. I have problem with station Digital 21164. I would recommend that you post on the comp.os.vms newsgroup to get more precise information, as this list is for discussing issues with the Perl language on OpenVMS. They will also need the exact model name that is on the computer system. The name that you have given is not known to me, and may not be precise enough to identify which system that you have. I lost setup to VMS boot. My operating system is OpenVMS Version 7,1-2. That is quite a bit old. The current version is 7.3-2. I didn´t get configuration the itens: Boot Name, Boot File and Os Path. You have the console operating system set to Windows NT mode. Those item names are not used with the OpenVMS console. This means that your system lost it's non-volatile memory or someone changed the configuration. I´d like to know how I can do configuration again, because I don´t information about it due this problem i need somebory help me. The folks on the comp.os.vms newsgroup would probably be able to give you the level of help that you need. -John [EMAIL PROTECTED] Personal Opinion Only
Re: MMK manual wanted
Michael G Schwern wrote: On Fri, Dec 17, 2004 at 07:24:06PM -0500, John E. Malmberg wrote: Thank you all. Now I have the set. I've posted them up here so I don't lose them again. http://www.makemaker.org/make_docs/ Unless you get written permission from HP to serve a copy of their documentation, you are in violation of their copyright. I realized that and I have put up a summary of my position on this issue on the make_docs page. I have no idea what HP's position would be. For most of HP's customers, there is a risk that HP will decide to stop putting updates on their web pages. The DECset documentation was just recently added to the web site after the HP merger with Compaq. I would recommend just posting a link to http://www.hp.com/go/openvms/doc/ and removing the link to the copy on your server. I can never find the MMS documentation off that page nor with the search nor with google. What's the magic keyword? Digital Module Management System At that page, part way down on what on Mozilla is the Left side, there is a link to DECset for OpenVMS That product is likely to be rebranded in the future to HPset for OpenVMS, or something similar. Following that link gets you to what today is: http://h71000.www7.hp.com/doc/decset.html And part way down is the Guide to Digital Module Management System Putting that string in http://www.google.com seems to indicate that there are many third party sites serving the HP OpenVMS documentation. In the past when I have followed the third party links, I have found that almost all of them are giving me 404 errors. -John [EMAIL PROTECTED] Personal Opinion Only
Re: [ANNOUNCE] ExtUtils::MakeMaker 6.25_07
[I am only monitoring [EMAIL PROTECTED] Michael G Schwern wrote: On Mon, Jan 03, 2005 at 12:53:03PM -0500, [EMAIL PROTECTED] wrote: Probably the directory target issue on older MMS' that Craig pointed out. Probably. My version of MMS is older than Craig's and is even less informative about the trouble than his was. Do these guys charge for upgrades or something? For commercial use: yes. There is a developer's partner's program where you pay one fee and get a suite of product licenses and media. Otherwise it requires either a support contract with right ot upgrade, or purchasing a single right to upgrade license + media. Contact your HP sales person for more details. For personal home hobby use there is no charge under the OpenVMS hobbyist program. http://www.openvmshobbyist.org/ -John [EMAIL PROTECTED] Personal Opinion Only
vmsperl was in the spamcop list.
Somehow the vmsperl mailing list got into the spamcop.net list. (reason: 530 5.7.1 Blocked - see http://www.spamcop.net/bl.shtml?63.238.179.181: Since this is a closed list, the only possibilities are: 1. The host had a security problem. (I really do not think that is likely) 2. One or more subscribers on the mailing list accidentally reported something from the mailing list as spam, and also confirmed that the mail list server was the source of the spam as a second step. The second is more likely, so please be careful. Spamcop rules specifically only allow mailing list administrators to report spam that comes from a mailing list. Now I do not know how many mailing lists share this server, so the report may not have been from a subscriber to this mailing list. Most of the time the spamcop.net used to figure out that the mailing list was not the source, however spammers found ways to take advantage of that. So now spamcop.net is phasing over to a mailhost configuration. If your spamcop.net account has been converted to the mailhost configuration, then if you report a mailing list message as spam, the parser will probably stop at the mail server and indicate it as the spam source. If the one of the mailing list administrators gets a spamcop.net account, and registers the mailing list server as one of their mailhosts, the spamcop.net parser is more likely to treat it as a trusted sender if someone accidentally reports spam in the past. Also, if you are a SpamAssasin user, and not yet on SpamAssasin 3, reports that I seen from the field is that SpamAssasin 3 is far more accurate than the earlier versions if you use the feature that checks the I.P. address of URLs in messages against the DNSbls. Thanks, -John [EMAIL PROTECTED] Personal Opinion Only
Re: vmsperl was in the spamcop list.
Craig A. Berry wrote: At 9:31 AM -0500 1/29/05, John E. Malmberg wrote: Somehow the vmsperl mailing list got into the spamcop.net list. (reason: 530 5.7.1 Blocked - see http://www.spamcop.net/bl.shtml?63.238.179.181: This has happened from time to time, but the address you show here is not the address of lists.develooper.com, the MTA for all the Perl mailing lists. 63.238.179.181 is for called qsl.net, which is where you are sending mail from. I am sorry, I should have noticed that it was my mail relay service I.P. address. But I am not sending from that I.P. address. The only e-mail that originates from that I.P. address is that of the owner of the QSL.NET service. All other e-mail from that I.P. address will only go to members of the QSL.NET service. So it must have been a member of QSL.NET that reported their own mail relay. Unless of course that QSL.NET had a security breach, which I doubt. As I am double subscribed to this list, I did not miss anything. I usually subscribe to mailing lists with the qsl.net e-mail address set to no mail because the QSL.NET spam filters are too aggressive for mailing lists, and sometimes will reject real e-mail from them, but just use qsl.net for posting because of the same spam filters foil most of the harvesting and worms. That no-mail option is not available on this mailing list. I will see if the encompasserve.org postmaster will whitelist the qsl.net I.P. address which will prevent this condition from happening the next time a qsl.net member has an accident. -John [EMAIL PROTECTED] Personal Opinion Only
blackholes.us and SpamAssassin.
Craig A. Berry wrote: It does look like the entire ISP is listed by blackholes.us: http://openrbl.org/zones/@ISP?63.251.223.163 but I'm not at all sure I know how to read that page. If this is causing problems for anyone, please write to the list owner. All that listing means is that the server is on an I.P. address allocated to a company in the U.S. Good to know. There is someone working on getting SpamAssasin working on VMS, but not as a MILTER. I do not know the status of that or if it is available for public download. They were looking for something that would compile PERL into a native binary to get the speed up. As I64 VMS uses the a similar ELF object language as LINUX on I64, if there is anything in the LINUX space for I64, it may be able to be ported to VMS on the I64 platform. -John [EMAIL PROTECTED] Personal Opinion Only
What is the stable version of Perl for VMS.
I notice that a lot of the tests here are on Perl 5.8.4, yet CPAN shows that the current version of Perl is 5.8.6. I am looking at building a version that supports the upcoming symlink support in OpenVMS, and wanted to know which base level of Perl I should start with. Also which baselevel has the changes that I submitted for handling UNIX file specifications based on the DECC$ feature logicals? Thanks, -John
Re: What is the stable version of Perl for VMS.
On Mon, 31 Jan 2005, Craig A. Berry wrote: At 7:07 AM -0500 1/31/05, John E. Malmberg wrote: I am looking at building a version that supports the upcoming symlink support in OpenVMS, and wanted to know which base level of Perl I should start with. New development should be done against the 5.9.x development stream known as bleadperl. The best way to get a copy is via rsync: $ rsync -avz --delete ftp.linux.activestate.com::perl-current perl This can be done on Linux, Mac OS X, under Cygwin on Windows, among other unixy environments, and the resulting directory tree zipped up and moved to VMS. Unless of course you've got your VMS port of rsync working (which I would be eager to know about). It is not quite there yet, but I have made significant progress over the past year. I have to convert a number of thread specific static and local variables to be in a thread specific structure, and I think I am past the 50% mark. Unfortunately until I get that step to 100%, I will not be able to do more than verify a converted module compiles. Some future version. We are still hampered by the fact that certain parts of the Perl core written in Perl need to be modified to accommodate the things the CRTL can do. If we don't develop and put in these changes simultaneously with your changes, basic functionality will break. For example, if someone has DECC$EFS_CASE_PRESERVE enabled and the C parts of Perl honor it but we have not yet modified MakeMaker to handle it, Perl won't even be able to build itself. I Would expect that it should be a reasonable restriction in at least the short term if not longer, that the CONFIGURE.COM and build scripts for Perl protect them selves from DECC$ feature logicals that prevent them from building. After all, the DECC$ feature logicals will affect the build now even with out the patches. The patches are only needed to make the behavior of the filenames that are not returned from the CRTL consistent with the feature logicals. So I apologize for how long this has taken. I've been short on volunteer time that comes in chunks bigger than half an hour, but I have not forgotten your changes. I was just thinking over the weekend that we need to move forward with this somehow, and we need also to look into supporting or using other v8.2 CRTL enhancements, such as stream-based pipes. Thanks for exploring symlink support. My assigned task now is to get a build of perl that when run under GNV will act like it is running on UNIX, with symlink support. It seems that a number of open source projects now require this. I think that most of the symlink related routines are already in the CRTL now in 7.3-2 and possilbly earlier, except that they will return an error if a symlink is attempted to be created with them, and they will always return the status of no symlinks being present. So programs that do not need to create symlinks or can tolerate that failing should be able to be built now and still work properly when run on a OpenVMS system that supports symlinks. One question that I have is if the Perl self tests will add symlink tests to what it runs if I enable the build of symlink support. I suppose that I will find out soon. Thanks, -John [EMAIL PROTECTED] [EMAIL PROTECTED] Personal Opinion Only
Minor ODS-5 build issue.
It appears that only a handful of files have multiple dots in them, and as near as I can tell, on OpenVMS, these files are only referenced by the CONFIGURE.COM script. It should not be to hard to change the configure script to be able to automatically on Alpha/I64 if those files like changes5^.8.* are in the multiple dot format or in an ODS-2 compatable name. -John [EMAIL PROTECTED] Personal Opinion Only
LARGEFILE configure issue
The configure tests for largefile support is based on if the integer type is native 64 bits. On VMS, the off_t type becomes 64 bits if the _LARGEFILE macro is defined in the test program. Which means logically the support for largefile on VMS should be based on the presences of off_t being detected as being 64 bits by the test program run by configure instead. (Or simply by checking the minimum version on the 64 bit OpenVMS platforms) If largefile support is to be present, then the resulting config.h needs to have a #define _LARGEFILE 1 in it. Of course there could be bad consequences if perl is assuming that off_t and int or long are interchangeable, which is what the current logic seems to suggest. Is there an easy solution to this? -John [EMAIL PROTECTED] Personal Opinion Only
Configuring socketpair() and statfs()
It appears that the perl source wants HAS_SOCKETPAIR defined if the host supports SOCKETPAIR, but the configure script only knows how to define it if d_sockpair='define'. A bit inconsistent and confusing. Perl seems to know about the standard C routine fstatvfs() and the non-standard fstatfs(). It does not seem to know about the standard C routine statvfs(), just the non-standard statfs(). Neither of these seem to be VMS specific issues. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Configuring socketpair() and statfs()
Craig A. Berry wrote: At 5:38 PM -0600 1/31/05, John E. Malmberg wrote: It appears that the perl source wants HAS_SOCKETPAIR defined if the host supports SOCKETPAIR, but the configure script only knows how to define it if d_sockpair='define'. A bit inconsistent and confusing. It does seem there's a conflation of whether the C routine socketpair() is present and whether the Perl opcode sockpair is available, but in practice it probably amounts to the same thing. So the define is for making the perl opcode do something, and thus it follows the perl opcode name instead of the library routine name? Perl seems to know about the standard C routine fstatvfs() and the non-standard fstatfs(). It does not seem to know about the standard C routine statvfs(), just the non-standard statfs(). If you have a specific need for statvfs(), I'm sure it could be added. I can't find any references in the Perl core to statfs(). Most likely Perl would operate on filehandles rather than file names when querying the file system, so it's not surprising we see it using fstatvfs() when it needs to do this. I have no specific need for it. Just noticed the define for it, and knew that it was provided in 8.2. Looks like configure.com needs to be updated to register the presence of socketpair and fstatvfs in VMS v8.2 and higher. If it's likely any of these will be made available on v7.3-2 via ECO, we should have real tests rather than just hard-wiring by VMS version. At this time, I am not aware of any plans to back port these features to before v8.2. Some of these new features are dependent on what is in the operating system for them to work. I have a test version of the 5.8.6 configure.com that is enabling those based on v8.2 being present. The statvfs() main use is it it allows a C program to easily check disk quotas for free space. -John [EMAIL PROTECTED] Personal Opinion Only
Re: LARGEFILE configure issue
On Mon, 31 Jan 2005, Craig Berry wrote: On Monday, January 31, 2005, John E. Malmberg wrote: The configure tests for largefile support is based on if the integer type is native 64 bits. I believe 64-bit integers and large file support now work correctly (and independently) in bleadperl and those changes should make it into 5.8.7. Unfortunately you did not implement the not very well documented but present lstat() routine which is about to start returning something different than stat(). It looks like I need to copy how stat() was done for lstat(). Also affecting this is now with 64 bit OpenVMS 8.2, there is a new struct stat that is incompatible with either struct mystat flavor in perl. It also removes most of the hacks that perl was doing to fill out the mystat structure. If largefile support is to be present, then the resulting config.h needs to have a #define _LARGEFILE 1 in it. I think I tried that, but that's too late. The CRTL headers that need to see _LARGEFILE get included before config.h, so it had to be added on the command line via /DEFINE=_LARGEFILE. Why not just #include config.h before including the other headers? It does not appear to do any harm to including it twice at a quick glance. Is there an easy solution to this? No, it wasn't easy, but the good new is wasn't is past tense. It was easier to port Perl to Itanium than it was to make it recognize and support the large file capabilities in the CRTL, but it's done and working as far as I know. Unless you want to take advantage of the new standard compliant stat() routines for 64 bit OpenVMS 8.2 to optimize the code. -John [EMAIL PROTECTED] Personal Opinion Only
Re: LARGEFILE configure issue
Craig A. Berry wrote: At 12:36 PM -0600 2/1/05, John E. Malmberg wrote: On Mon, 31 Jan 2005, Craig Berry wrote: I believe 64-bit integers and large file support now work correctly (and independently) in bleadperl and those changes should make it into 5.8.7. I do not have bleadperl, but they are not in a snapshot of 5.9.1 I downloaded a few days ago. I just put them in my local copy of 5.8.6, but have not had time to test them. Unfortunately you did not implement the not very well documented but present lstat() routine which is about to start returning something different than stat(). It looks like I need to copy how stat() was done for lstat(). I'm quite sure that we don't check for all routines that are now supported and documented in the CRTL, so it doesn't surprise me that something unknown outside of OVMS Engineering would not be tested for in configure.com. It should be a simple addition, though, to test for lstat() in configure.com. Is it available on all 8.2 systems, or will it only appear later? It is not in the version dependency tables or anywhere else in the brand new CRTL manual dated January 2005. I will have to check to find out why lstat() is missing from the documentation where it should be. It is referenced in the documentation as a cross reference to a related feature. I am not sure how long lstat() has been present in the CRTL, until symbolic links start working, it should return the same as stat(). Also affecting this is now with 64 bit OpenVMS 8.2, there is a new struct stat that is incompatible with either struct mystat flavor in perl. It also removes most of the hacks that perl was doing to fill out the mystat structure. I believe the original hack was because existing code would compare st_ino members of the stat structure to see if two files are the same. Since the old VMS stat structure made st_ino an array of words, only the first word would be compared, which was insufficient for determining equality. So if we can do away with that in 8.2 and later and simply make mystat an alias for stat, I'm all for it. As it is unlikely that this will be backported, the old method will need to be conditionally compiled. A number of code porting projects suffered from the problems that you described. I have a TPU macro that does a search and replace on the inode assigns and compares, which changes them to memcpy and memcmp. With 8.2, the ino_t is a 64 bit integral value, so number assigns and compares will work. With 8.2, the dev_t value will also be valid when you use the standard stat variant, so that hack disappears. But I notice that perl allows the script to choose local time or UTC for what stat() outputs, so some of the wrapper will still be needed. If largefile support is to be present, then the resulting config.h needs to have a #define _LARGEFILE 1 in it. I think I tried that, but that's too late. The CRTL headers that need to see _LARGEFILE get included before config.h, so it had to be added on the command line via /DEFINE=_LARGEFILE. Why not just #include config.h before including the other headers? It does not appear to do any harm to including it twice at a quick glance. Because config.h is included from perl.h, and perl.h must be included after either EXTERN.h for modules that reference globals, or INTERN.h, for modules that define globals. Even if changing the order appears to work now, there is no telling what dependencies might show up based on current documented order of inclusion. I noticed that this seems to be done on other platform variants. -John [EMAIL PROTECTED] [EMAIL PROTECTED] Personal Opinion Only
stat() and the NLA0: device.
I notice that Perl is checking if the stat is being done on the NULL device, and generating a fake stat structure. Is there a specific version of stat() on OpenVMS that does not return the correct data for stat? stat() should return the correct information from either a filespec of NLA0: or NL: or even /dev/null -John [EMAIL PROTECTED] Personal Opinion Only
Re: stat() and the NLA0: device.
On Thu, 3 Feb 2005, Craig A. Berry wrote:
At 11:29 AM -0600 2/3/05, John E. Malmberg wrote:
On Wed, 2 Feb 2005, Craig A. Berry wrote:
At 2:41 PM -0600 2/2/05, John E. Malmberg wrote:
With OpenVMS 8.2 and when using the standard compliant stat structure,
the code handling the NULL device is producing the wrong answer.
Go ahead and conditionalize it out when __CRTL_VER is older than the
earliest version you can easily test with or find documented in CRTL
ECOs: 7.2, 7.3, or whatever. If we can move the version number
back at some point, so much the better, but not a priority since the
workaround does work on all pre-8.2 versions as far as I know.
In looking at what it would take to use the standard stat structure in
Perl, the only stumbling block I am seeing is the routine Perl_cando().
With the standard compliant stat, there is no pointer to the device name,
instead a unique 64 bit number for the st_dev member is returned, and
I am currently ignorant of anyway to use that to determine the real device
name as Perl_cando() needs.
Until that is resolved, building Perl with _USE_STD_STAT will not work
right.
Ah, good, we can also conditionalize out the encode_dev() hack, which
has served us well for years but shouldn't be necessary with the new
stat structure if I understand what you are saying. The reason that
Perl_cando() uses the device name from the stat structure is that
lib$fid_to_name returns a device name that may not be up to snuff.
For example, it will return DISK$USER as the device name if the
volume label is USER even if DISK$USER has been overriden by an outer
mode logical. I'm not sure if that helps, and I'm not sure what to
suggest about st_devnam.
A partial answer is that a translation of the innermode logical name that
was set up by the mount command can be used to get the real device name.
I will have to look if the existing routines in vms.c can be used to get this.
And with the _LARGEFILE option, mystat might as well use __ino64_t for
the ino_type and not use the rvn and fill members.
Hmm. I'll try to look at that sometime. Is that only when
_USE_STD_STAT is in effect, or regardless?
Regardless. Look at the code in stat.h.
Also, the dbgminiperl.exe is not being LINKED/DEBUG, should it be?
Now I have to use LINK/DEBUG before running the build.
What do you see when you do
$ search config.sh vmsdebug
config_args='-Dusedevel -Dusevmsdebug -des'
usevmsdebug='define'
That was a while back and I did not save config.sh file. The code got
compiled /DEBUG, just nothing was linked in debug.
I also discovered that CONFIGURE.COM does not protect itself from
LINK :== link/debug
I am chasing down my next problem now.
@make_ext Sys$Disk:[]miniperl.exe MMS
Making attrs (dynamic)
Descrip.MMS out-of-date with respect to MAKEFILE.PL, [--.LIB]CONFIG.PM,
[--]CONFIG.H
Cleaning current config before rebuilding Descrip.MMS ...
Rename/NoConfirm Descrip.MMS Descrip.MMS_old
MMS /Descrip=Descrip.MMS_old clean
MCR [--]miniperl.exe -I[--.lib] -I[--.lib] -MExtUtils::Command -e rm_f *.M
ap *.Dmp *.Lis *.cpp *.exe *.obj *.olb *.Opt attrs.bs attrs.bso .MM_Tmp
MCR [--]miniperl.exe -I[--.lib] -I[--.lib] -MExtUtils::Command -e rm_rf
[--.lib.auto.attrs]extralibs.all attrs.c pm_to_blib.ts Makeaperl.MMS perlmain.c
MCR [--]miniperl.exe -I[--.lib] -I[--.lib] -MExtUtils::Command -e rm_rf
[--.lib.auto.attrs]extralibs.ld blib pm_to_blib
MCR [--]miniperl.exe -I[--.lib] -I[--.lib] Makefile.PL INST_LIB=[--.lib]
INST_ARCHLIB=[--.lib] PERL_CORE=1
Writing Descrip.MMS for attrs
Descrip.MMS has been rebuilt.
Please run MMS to build the extension.
Skip [--.lib]attrs.pm (unchanged)
MCR [--]miniperl.exe -I[--.lib] -I[--.lib] -e use ExtUtils::Mksymlists;
-e Mksymlists('NAME' = 'attrs', 'DL_FUNCS' = { }, 'DL_VARS' = [],
'FUNCLIST' = [])
MCR [--]miniperl.exe -e print [--.lib.auto.attrs]attrs.olb/Include=attrs\n[--
.lib.auto.attrs]attrs.olb/Library\n; ATTRS.OPT
MCR [--]miniperl.exe -e print qq{[--]DBGPerlShr.exe/Share\n} ATTRS.OPT
MCR [--]miniperl.exe -e print qq{[--]DBGPerlShr.exe/Share\n} ATTRS.OPT
Copy/NoConfirm ATTRS.OPT [--.LIB.AUTO.ATTRS]ATTRS.OPT
%MMS-F-GWKNOACTS, Actions to update ATTRS.C are unknown.
%MMS-F-ABORT, For target DYNEXT, CLI returned abort status: %X10EE805C.
Inspecting the resuling DESCRIPT.MMS shows the dependency and the translation
of the MMS macro that are failing:
XSUBPPDEPS = [--.lib.ExtUtils]typemap
attrs.c : $(XSUBPPDEPS)
And it is right, there is no rule for how to build attrs.c if it is missing
or that rule fails.
So not being able to figure out what the problem is, I backed out all the
changes that I have made to 5.8.6 and ran the configure with -de option.
As I am typing it, it just stopped at:
$ @BUILD_ROOT:[00]configure.com -de
$mms
MCR Sys$Disk:[]miniperl.exe -I[.lib] -I[.ext.re] [.lib.extutils]xsubpp -nop
Perl v0.0.0 required--this is only v5.8.6, stopped at [.lib.extutils]xsubpp lin
%SYSTEM-F-ABORT, abort
%MMS-F
5.8.6 - %MMS-F-GWKNOACTS, Actions to update ATTRS.C are unknown.
On Thu, 3 Feb 2005, John E. Malmberg wrote:
I am chasing down my next problem now.
@make_ext Sys$Disk:[]miniperl.exe MMS
Making attrs (dynamic)
Descrip.MMS out-of-date with respect to MAKEFILE.PL, [--.LIB]CONFIG.PM,
[--]CONFIG.H
Cleaning current config before rebuilding Descrip.MMS ...
Rename/NoConfirm Descrip.MMS Descrip.MMS_old
MMS /Descrip=Descrip.MMS_old clean
MCR [--]miniperl.exe -I[--.lib] -I[--.lib] -MExtUtils::Command -e rm_f
*.M
ap *.Dmp *.Lis *.cpp *.exe *.obj *.olb *.Opt attrs.bs attrs.bso .MM_Tmp
MCR [--]miniperl.exe -I[--.lib] -I[--.lib] -MExtUtils::Command -e rm_rf
[--.lib.auto.attrs]extralibs.all attrs.c pm_to_blib.ts Makeaperl.MMS
perlmain.c
MCR [--]miniperl.exe -I[--.lib] -I[--.lib] -MExtUtils::Command -e rm_rf
[--.lib.auto.attrs]extralibs.ld blib pm_to_blib
MCR [--]miniperl.exe -I[--.lib] -I[--.lib] Makefile.PL INST_LIB=[--.lib]
INST_ARCHLIB=[--.lib] PERL_CORE=1
Writing Descrip.MMS for attrs
Descrip.MMS has been rebuilt.
Please run MMS to build the extension.
Skip [--.lib]attrs.pm (unchanged)
MCR [--]miniperl.exe -I[--.lib] -I[--.lib] -e use ExtUtils::Mksymlists;
-e Mksymlists('NAME' = 'attrs', 'DL_FUNCS' = { }, 'DL_VARS' = [],
'FUNCLIST' = [])
MCR [--]miniperl.exe -e print
[--.lib.auto.attrs]attrs.olb/Include=attrs\n[--
.lib.auto.attrs]attrs.olb/Library\n; ATTRS.OPT
MCR [--]miniperl.exe -e print qq{[--]DBGPerlShr.exe/Share\n} ATTRS.OPT
MCR [--]miniperl.exe -e print qq{[--]DBGPerlShr.exe/Share\n} ATTRS.OPT
Copy/NoConfirm ATTRS.OPT [--.LIB.AUTO.ATTRS]ATTRS.OPT
%MMS-F-GWKNOACTS, Actions to update ATTRS.C are unknown.
%MMS-F-ABORT, For target DYNEXT, CLI returned abort status: %X10EE805C.
Inspecting the resuling DESCRIPT.MMS shows the dependency and the translation
of the MMS macro that are failing:
XSUBPPDEPS = [--.lib.ExtUtils]typemap
attrs.c : $(XSUBPPDEPS)
And it is right, there is no rule for how to build attrs.c if it is missing
or that rule fails.
So not being able to figure out what the problem is, I backed out all the
changes that I have made to 5.8.6 and ran the configure with -de option.
I did a $MMS realclean and now I am getting the same build error with all
files from the 5.8.6 kit.
It looks like for some reason either MAKEMAKER is not generating the required
action line, or that the dependency line should really be something like:
attrs.c : attrs.xs $(XSUBPPDEPS)
which there is a rule for. But I am not sure what to do get beyond this point.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Re: 5.8.6 - %MMS-F-GWKNOACTS, Actions to update ATTRS.C are unknown.
Craig A. Berry wrote: At 3:52 PM -0600 2/3/05, John E. Malmberg wrote: I'm pretty sure this is an MMS bug. I've never been able to whittle it down to a really simple reproducer, but removing MMS from the equation or removing mixed-case filenames from the equation has always solved the problem. It's probably comparing .xs with .XS somewhere, not finding a match, and deciding it doesn't have a rule to apply. On the todo list for Monday, make a small reproducer and submit a bug report for MMS. It looks like for some reason either MAKEMAKER is not generating the required action line, or that the dependency line should really be something like: attrs.c : attrs.xs $(XSUBPPDEPS) That makes it explicit, but the impliicit rule should work. I have always used explicit rules in the .MMS scripts that I write, even on ODS-2 I have had problems getting some implicit rules to work, so I gave up trying a long time ago. Switch to MMK or force your filenames to be all upper case by unpacking your archive like so: Installing MMK is faster than unpacking the archive again. Has anyone tried using the GNV supplied make to build Perl? The configure.com script seems to find it. -John [EMAIL PROTECTED] Personal Opinion Only
Re: GNU make (was Re: 5.8.6 - %MMS-F-GWKNOACTS, Actions to update ATTRS.C are unknown.)
Craig A. Berry wrote: When GNV gets to the point where we can use Configure rather than configure.com and stop maintaining a separate behemoth configuration script, that's the point where we will need to update support for GNU make. There are people looking at getting GNV so that it can handle configure scripts better. Right now though, it is only being supported by HP on 64 bit platforms. I do not know if the current GNV source kit will build on VAX. I noticed the post on comp.os.vms about bug reports/fixes to GNV posted to sourceforge being unanswered, and I will try to find out what is happening there. As I remember things, the Source Forge GNV site was set up by OpenVMS users, and not by what is now HP. That may be contributing to the communications problem with items posted there. Be assured, bug reports are wanted, and fixes are even more wanted. :-) In the case of the INFO-ZIP and VMSTAR that are bundled with GNV, these are basically maintained externally to GNV and HP, and the HP GNV maintainers are trying to coordinate changes to them with those maintainers. Interestingly enough, SAMBA V4 seems to have changed to using Perl to generate their configuration information. Other open source projects are also using Perl as part of their build process. And one of the bottlenecks on some of these processes is that they need perl to only use UNIX format file specifications. Also, to answer your other question, lstat() showed up in 7.3-1 according to the C header files. Until 8.2 + future RMS SYMLINKS ECO kit, it behaves the same as stat(), and if support for lstat() is not configured, Perl already knows to substitute stat(). And there is no plans to backport these changes to earlier VMS versions or to implement them on VAX. -John [EMAIL PROTECTED]
Re: Where were we at?
[Only subsribed to vmsperl] On Mon, 7 Feb 2005, Michael G Schwern wrote: On Sat, Jan 29, 2005 at 05:44:20PM -0600, Craig A. Berry wrote: That was my first theory as well, but that's not it. It's the result of the fact that I have a logical name bin defined, so it looks for bin/foo there rather than in the local relative path. Simply prepending ./ seems to do the trick: [snip] succeeds because the additional syntax disambiguates it. We had to do something like this to File::Find some time ago. Do you want a patch to cp_if_diff in Manifest.pm or do you already have an idea of how you want to handle this? I'm of half a mind to just say that having a logical called 'bin' is likely to break lots of unixy software if it makes bin/foo unsafe. I'm sure there's lots of other places in MakeMaker which use foo/bar to mean ./foo/bar and something else will just break in the future. In fact I'm a little surprised it hasn't. Could you check if it applies to Copen(F, qq/$ARGV[0]/) as well? cp_if_diff() is one of the few places that uses in open in MakeMaker. If the feature logical DECC$UNIX_PATH_BEFORE_LOGNAME is defined as ENABLE, the the CRTL will try [.bin] before it tries bin: for bin/. This is documented in the OpenVMS 7.3-1 manual, so I do not know if it is available earlier. The other applicable feature, available for OpenVMS 7.3 and later which is overridden by the above is: DECC$DISABLE_TO_VMS_LOGNAME_TRANSLATION, which when enabled will always interpret bin/ as [.bin] and will attempt to use /bin as bin: first. Defining the logical name bin as a search list should also work on any version of OpenVMS. -John [EMAIL PROTECTED] [EMAIL PROTECTED] Personal Opinion Only
Re: GNU make lstat() topic
On Sun, 6 Feb 2005, Craig A. Berry wrote: At 7:30 PM -0500 2/4/05, John E. Malmberg wrote: Craig A. Berry wrote: When GNV gets to the point where we can use Configure rather than configure.com and stop maintaining a separate behemoth configuration script, that's the point where we will need to update support for GNU make. I modified my local copy of the configure.com to accept a -Dbuilder=make so that on the command line I could set the default. The build failed because [.vms]Makefile.in was not found. So I am now falling back to MMK. Perl has been able to use unix syntax file specification for 10 years or so. If what you mean is the behavior that results from DECC$FILENAME_UNIX_REPORT, that's a different matter. This is a really a problem with other packages not handling file specs reported in VMS syntax. Perl's tendency is that, when in doubt, convert to native syntax. This was essential for older CRTL versions that often did not handle unix syntax fully. But reporintg filenames in VMS syntax will of course cause trouble for other packages that can't handle that. So yes, there is work to be done in Perl to make it only report unix syntax filenames. It apparently a case where the perl script output is expected to be used by an application that does not understand VMS file specifications. I am going by second hand knowledge here. When I actually try to build one of these products, I may find out more information. On my 7.3-1 system: $ search sys$library:decc$crtl.exe lstat %SEARCH-I-NOMATCHES, no strings matched Wrong image file, try: $ search sys$share:decc$shr lstat/format=nonull I suppose it could be a macro that references decc$stat, though I see no evidence of that in the header. Until 8.2 + future RMS SYMLINKS ECO kit, it behaves the same as stat(), and if support for lstat() is not configured, Perl already knows to substitute stat(). And there is no plans to backport these changes to earlier VMS versions or to implement them on VAX. We'll have to explicitly test for lstat in configure.com, including some sort of test that it not only is present in the CRTL but actually works, i.e., has the underlying OS support. The 8.2 CRTL will do the right thing even if the actual SYMLINK support is missing, so just a test for 64 bit OpenVMS 8.2 should be all that is needed for Configure.com. The only thing that would be significant to test for is if a symbolic link can be created. I have not looked at what Perl does in that case that is different than if the symlink() routine is missing. No need to test for earlier versions, the routines will just return the same results as if they did not find a symlink for the argument that was called. -John [EMAIL PROTECTED] [EMAIL PROTECTED] Personal Opinion Only
Re: ODS-5 Filenames
On Wed, 9 Feb 2005, Atkinson, Robert wrote: I'm using TXT2PDF from Sanface Software. We've converted some of our disks to ODS-5, but now find that the files generated from uppercase filenames are created in lower case. The user process has the PARSE_STYLE parameter set to TRADITIONAL, so that files are created in uppercase by default, but this appears to make no difference within Perl. This is the code :- $output.=$out; $verbose and print Changing to uppercase\n; $output=uc($out); open (OUT, $output) || die $producer1: couldn't open output file $output\n; And the output is :- Processing SYS$TEMP:TEST_20050209_BFAD.TXT file Processing VMS file Changing to uppercase Writing TEST_20050209_BFAD.PDF file But the file created is in lowercase :- Directory SY0:[LIVE.TMP] test_20050209_bfad.pdf;11 14/529-FEB-2005 14:43:40.30 TEST_20050209_BFAD.TXT;2 4/529-FEB-2005 14:08:36.38 Just before running Perl, try: $define/user decc$efs_case_preserve enable See if it makes a difference. If it does, then it needs to be decided if PERL should take this action by default if the user does not explicitly set the decc$efs_case_preserve feature logical before running perl. -John [EMAIL PROTECTED] Personal Opinion Only
RE: ODS-5 Filenames
On Wed, 9 Feb 2005, Atkinson, Robert wrote: No joy, I'm afraid! This is the code :- $output.=$out; $verbose and print Changing to uppercase\n; $output=uc($out); open (OUT, $output) || die $producer1: couldn't open output file $output\n; Can you produce a simple reproducer, including the smallest amount of Perl code and DCL needed to demonstrate the problem? Perl should be uppercasing filespecifications as they are read in, so having the file in lowercase should not be an issue. -John [EMAIL PROTECTED] Personal Opinion Only
Quotas and disk space requirements for build/test Perl?
Is there some documentation on how much disk space is needed to build and test Perl normally or in debug? The debug build appears to be very large, this mainly seems to be from the listing files. A debug build with out the listing files might be easier to manage. Also can some guidance be given on what account quotas are needed for the different platforms? Once these are known, it should not be hard to add them to the configure.com script to do a sanity check. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Quotas and disk space requirements for build/test Perl?
Michael G Schwern wrote: On Wed, Feb 09, 2005 at 10:30:04PM -0500, John E. Malmberg wrote: Except won't that number change based on compiler and architecture not to mention keeping it up to date with each version of Perl? Is disk really that expensive? I had to dedicate an RF72 on my VAX 4000-500 in order to do a debug build. I can not afford to add more disks to my hobby system, as all three DSSI bays are full, and I do not have a DSSI to SCSI converter. Disk space can be a premium on older or hobby systems. I have run out of disk space on two systems that I have attempted to do debug builds. But disk space is the minor issue compared to the quotas. Or am I just missing something being a Unix user? I am having issues with the testing phase hanging, and I am assuming that it is process quota related. -John [EMAIL PROTECTED] Personal Opinion Only
lstat() and hardlinks start with OpenVMS 7.3-1
On Sun, 6 Feb 2005, Craig A. Berry wrote: We'll have to explicitly test for lstat in configure.com, including some sort of test that it not only is present in the CRTL but actually works, i.e., has the underlying OS support. According to the new features documentation for 7.3-1, link() and the related routines except for symlink() were implemented and supported. The link() routine only works on ODS-5 volumes that have been enabled for hardlinks. Currently if you build perl with d_link and friends, defined, two perl modules will attempt use it to create hard links instead of copies on the build disk in at least two places. So that would imply that the build disk needs to be ODS-5 and have hard links enabled. The only issue with that is that the f$getdvi() call to let you that information does not seem to have shown up until OpenVMS 8.2. I have not checked if SYS$GETDVI() will return that information or if for older versions the output of show device/full would be needed. Once you get past that, those two perl modules still fail to create the hard link because they have VMS specific code to append .com to the file they are creating where it is created, but that file extension is not there when the new name is linked, or a copy made. It appears that the syscopy module calls an rmscopy module that somehow figures out to try some extensions. Those modules are: Directory BUILD_ROOT:[00.utils] c2ph.PL;1 76 10-FEB-2005 13:24:12.81 (RWED,RWED,RE,) Directory BUILD_ROOT:[00.x2p] s2p.PL;1 107 10-FEB-2005 15:22:08.05 (RWED,RWED,RE,) So in order to get the build to complete, these modules need to be changed to either always copy on OpenVMS, or use the extension on the link operation. I have not checked the perl source to see if there are other places hard links are used where I did not have to make any changes. symlinks() will be a different issue, and they will likely require POSIX style filespecifications given to them. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Quotas and disk space requirements for build/test Perl?
On Thu, 10 Feb 2005, Michael G Schwern wrote: On Thu, Feb 10, 2005 at 07:27:43AM -0500, John E. Malmberg wrote: I had to dedicate an RF72 on my VAX 4000-500 in order to do a debug build. I can not afford to add more disks to my hobby system, as all three DSSI bays are full, and I do not have a DSSI to SCSI converter. Disk space can be a premium on older or hobby systems. I have run out of disk space on two systems that I have attempted to do debug builds. Obviously I am missing something. Can't you pick up a used 10 gig IDE disk for $20 these days? The adapters to connect it to a VAX that does not have built in SCSI will cost at least $300 to $1000 for the Q-BUS to SCSI (used and apparently still in high demand) + the IDE to SCSI converter which was a few hundred $ the last time I checked with no one yet admitting to have gotten that unspported configuration to work. Some of the IDE to SCSI converters are known not to work with OpenVMS because they have not implmented the SCSI features that OpenVMS uses. A Russian posted the schematics for their Q-BUS to IDE adapter on the Internet a few years back. The drivers are only for 4.x of VAX/VMS. Only some of the later generation of Alpha systems can take IDE drives, and then they are limited to 137 GB. Just how big are these debug builds? The one that I just got completed is showing to be 1.37 GB in size. Out of a 4 GB disk. I notice that there is some mention in the documenation of Perl that indicates that it is currently about 80 MB of source. Or are we talking some really old hardware here? Old OpenVMS systems seem to stick around for ever. :-) -John [EMAIL PROTECTED] Personal Opinion Only
Changing osname or ^O from VMS.C at startup?
It appears that the VMS specific file name behavior is tied to many perl scripts that are checking the ^O for 'VMS'. What I would like to investigate is having a option where a symbol or logical name could be used by the init and pre-init code in VMS.C to change the ^O to report 'GNV'. That same feature would also cause the DECC feature settings to go to full UNIX/POSIX filename compatibility mode. In investigating why the first standard test for symlinks on perl was failing, it turns out that the fast_abs_path() and abs_path() call VMS specific code including using rms calls to return the path. This existing code does not know how to follow a symbolic link to the real path, and since other code calls those same routines that should not return a real path, but the link value, a new routine would be needed for the abs_path routines to use. Alternatively, symbolic links virtually require UNIX/POSIX path names to function, which means that they are most likely only to be used in a full POSIX environment. It looks like when Perl does not recognize the value of ^O, it defaults to POSIX/UNIX behavior on file handling. I have not found out yet how to read or change the value of ^O from C, as it seems to only be set by config.pm, and I am not sure if config.pm is used after Perl is built. If anyone has any suggestions on an easy way to do this, please let me know. Thanks, -John [EMAIL PROTECTED] Personal Opinion Only
Re: Changing osname or ^O from VMS.C at startup?
On Tue, 15 Feb 2005 [EMAIL PROTECTED] wrote: John E. Malmberg [EMAIL PROTECTED] wrote on 02/15/2005 03:21:01 PM: If anyone has any suggestions on an easy way to do this, please let me know. I'd recommend rewriting config.h before you compile perl under GNV, later you could modify the Configure script itself to recognize GNV as a distinct osname. Here for example is how perl 5.8.1 is built to recognize VMS: Yes, I modified the configure.com script to allow osname=GNV. The build has completed and it is running the tests now. I am noticing on a previous build that a number of the tests are failing when you build with the VMS DEBUG option, and the tests use PERLSHR instead of DBGPERLSHR. When the tests are run using DBGPERLSHR they succeed. This is telling me that when the VMS DEBUG option is selected, PERLSHR is not being built correctly. $ search PERL_ROOT:[LIB.VMS_AXP.5_8_1.CORE]config.h osname /* OSNAME: #define OSNAME VMS/**/ Of course changing that and recompiling does not give you the flexibility of a symbol or logical that you requested. However there is precedent for such a distinct setting of $^O. Namely the Windows native port calls itself 'MSWin32' whereas the cygwin (GNU/bash et al) environment calls itself 'cygwin' in perl's $^O variable. Yes, I noticed that. The cygwin is a more isolated container environment than GNV is, and while I might have to settle for a separate binary, I would prefer that a system could have one installation of Perl for all of it's uses. That the build proceded completed with the -Dosname=GNV and the self tests are generating an active display on the monitor system command is encouraging. -John [EMAIL PROTECTED] Personal Opinion Only
Debugger - was: Changing osname or ^O from VMS.C at startup?
On Tue, 15 Feb 2005, Craig Berry wrote: On Tuesday, February 15, 2005, at 03:21PM, John E. Malmberg wrote: I am noticing on a previous build that a number of the tests are failing when you build with the VMS DEBUG option, and the tests use PERLSHR instead of DBGPERLSHR. When the tests are run using DBGPERLSHR they succeed. This is telling me that when the VMS DEBUG option is selected, PERLSHR is not being built correctly. When you configure and build for the VMS debugger, there is not supposed to be a PERLSHR.EXE, only DBGPERLSHR.EXE. If you build in debug without configuring for it, you will see the symptoms you describe. Switching back and forth between a debug and non-debug build without reconfiguring is not supported. If you are configuring for the debugger and still seeing this issue, please holler. Hollering. I did a MMK realclean between the builds, which gets rid if any dangling executables. Directory BUILD_ROOT:[00] DBGMINIPERL.EXE;1 7269 15-FEB-2005 16:20:51.35 (RWED,RWED,RE,) DBGPERL.EXE;1 52 15-FEB-2005 16:21:56.35 (RWED,RWED,RE,) DBGPERLSHR.EXE;17469 15-FEB-2005 16:21:54.61 (RWED,RWED,RE,) MINIPERL.EXE;3 4111 15-FEB-2005 16:54:19.09 (RWED,RWED,RE,) MINIPERL.EXE;2 4111 15-FEB-2005 16:54:17.57 (RWED,RWED,RE,) MINIPERL.EXE;1 3873 15-FEB-2005 16:20:53.78 (RWED,RWED,RE,) NDBGperl.exe;1 8 15-FEB-2005 16:21:56.72 (RWED,RWED,RE,) PERL.EXE;1 6 15-FEB-2005 16:54:46.44 (RWED,RWED,RE,) PERLSHR.EXE;1 3441 15-FEB-2005 16:54:45.53 (RWED,RWED,RE,) Ahhh Apparently the MMK/FROM_SOURCES TEST is creating the non debug version for it's use, and that is causing the tests to fail. So I need to modify that command in my master build file to also have the /macro=__DEBUG__=1 for that MMK command. BTW, the simplest way to configure for the debugger is: $ @configure -Dusevmsdebug -des Currently I am using: $ @build_root:['root']configure.com -Dusevmsdebug - -Dunlink_all_versions -Duselargefiles -Dusesymlinks - -Dusehardlinks -Dosname=GNV -de If the GNV build works, I am going to make it imply: unlink_all_versions, uselargefiles, usesymlinks, and usehardlinks, and possibly enabling all 64 bit options. I plan to also put in vms.h the #ifdef for the GNV environment to set the C feature logical to default to that all file specifications will be in UNIX format and case sensitive, unless the user overides this. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Changing osname or ^O from VMS.C at startup?
On Tue, 15 Feb 2005, Craig Berry wrote: On Tuesday, February 15, 2005, at 02:21PM, John E. Malmberg [EMAIL PROTECTED] wrote: It appears that the VMS specific file name behavior is tied to many perl scripts that are checking the ^O for 'VMS'. What I would like to investigate is having a option where a symbol or logical name could be used by the init and pre-init code in VMS.C to change the ^O to report 'GNV'. That same feature would also cause the DECC feature settings to go to full UNIX/POSIX filename compatibility mode. The global PL_osname is set in S_init_predump_symbols in perl.c, which is called from S_parse_body when a Perl script is compiled. If you put in your own value in start-up code, I'm pretty sure it will get overwritten later. You could stick some code in S_init_predump_symbols to check for a logical name and reset accordingly. That might be a little dangerous since we don't really know what side effects there might be to dynamically changing the OS name. Apparently the OS name is dynamically set now by a perl script, config.p*, and I can not find a pre-compiled version of it. So what I think I might try is modifying that script to change the OS type and see what happens. If you can live with configuration time changes, look for $ osname = F$EDIT(F$GETSYI(NODE_SWTYPE),COLLAPSE) in configure.com and modify it to say whatever you want. I missed changing that to only be set if osname was not previously defined, so my last build was still with osname=VMS. I did find the test later on that bails if the osname .nes. VMS It turns out now, that perl will not build if the osname is not VMS, it is failing on opendir(./../../), and I have not found a way to get around that yet. So it looks like I need to change the osname after the build is complete. The value in config.h is not used by any of the C code. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Changing osname or ^O from VMS.C at startup?
Craig A. Berry wrote: At 5:14 PM -0600 2/15/05, John E. Malmberg wrote: On Tue, 15 Feb 2005, Craig Berry wrote: The global PL_osname is set in S_init_predump_symbols in perl.c, which is called from S_parse_body when a Perl script is compiled. If you put in your own value in start-up code, I'm pretty sure it will get overwritten later. You could stick some code in S_init_predump_symbols to check for a logical name and reset accordingly. That might be a little dangerous since we don't really know what side effects there might be to dynamically changing the OS name. Apparently the OS name is dynamically set now by a perl script, config.p*, and I can not find a pre-compiled version of it. So what I think I might try is modifying that script to change the OS type and see what happens. That's not dynamic in the sense of being set at run time. Config is hard-wired to return the same value that's in config.h: $ perl -V:osname osname='VMS'; config.h has the C macro OSNAME, which is in turn used by S_init_predump_symbols as I mentioned above. Config the Perl module and config.h the C header both get their values from config.sh, which is generated at configuration time by configure.com. I did a search of the source code before I posted, while the osname macro is defined in config.h, I can not find anything in the perl .C files that reference any of the osname macros in any of the .H files, or any macros that would hide such references. I will have to look at the S_init_predump_symbols to see if that gives me any more clues. Thanks, -John Personal Opinion Only
Re: Changing osname or ^O from VMS.C at startup?
Craig A. Berry wrote: At 12:32 AM -0500 2/16/05, John E. Malmberg wrote: $ search/exact *.c OSNAME ** D0:[CRAIG.PERL-5_8]perl.c;1 PL_osname = savepv(OSNAME); Some how I must have missed that one. The help of this mailing list has been of great assistance, these modifications that I am attempting, and I am sure I will probably need more. It looks like changing the osname is not the way to do what I need done. I am still working on getting the symlink support going but there are significant implications to using symbolic links on OpenVMS once the ECO kit is available. Perl is affected by this, so here is a preview: Symbolic links introduce and for some operations require the use of a new UNIX style filename convention that is being called POSIX format. The processing of these specifications is now done by RMS and not by the CRTL so there is a way to use them with almost all existing OpenVMS programs. Because of the differences in processing a symbolic link references, any program that does it's own translation of file specifications from UNIX format to OpenVMS native format will not return the right answer for symbolic links. The CRTL will have a new feature setting to indicate when the user has selected that UNIX style pathnames should be parsed in POSIX style, and while I can easily test for this in the C code, but it looks like I would need a way to let the .PM scripts know that this feature has been activated by the user in order to for the special cased OpenVMS code to work with symbolic links. The perl absolute path routine is one of the ones that is affected by this as it is special cased for OpenVMS to do a manual parse of the filename. It looks like the way to do that is to have the affected scripts look up the setting of the DECC feature logicals while they run. -John [EMAIL PROTECTED] Personal Opinion Only
Re: symlink support
Craig A. Berry wrote: At 6:21 PM -0500 2/18/05, John E. Malmberg wrote: I am still working on getting the symlink support going but there are significant implications to using symbolic links on OpenVMS once the ECO kit is available. Perl is affected by this, so here is a preview: Symbolic links introduce and for some operations require the use of a new UNIX style filename convention that is being called POSIX format. The processing of these specifications is now done by RMS and not by the CRTL so there is a way to use them with almost all existing OpenVMS programs. Because of the differences in processing a symbolic link references, any program that does it's own translation of file specifications from UNIX format to OpenVMS native format will not return the right answer for symbolic links. I find this curious, since I'm not aware of any difference in the syntax of a filename that indicates whether or not it's a symbolic link on unix systems. What is there about the file specification of a symbolic link that cannot be expressed in VMS syntax? It is expressible in VMS syntax, it is just that currently the CRTL routines that operate on symbolic links require POSIX syntax, not VMS syntax. I do not know if that limitation will be removed in the future. RMS will deal with symbolic links transparently, using RMS routines to non-transparently operate on symbolic links requires special coding. The most obvious case shows up with the file [.testlink] that is a symbolic link to _a_/_deeper_/_directory_/_level_ From the CRTL with POSIX file translations enabled, doing a dir of testlink/../ will give you the files in _a_/_deeper_/_directory_/ Translating that to a VMS format requires that the translation routine knows when it has encountered a symbolic link. Much easier just to let the CRTL deal with it. And DCL will not know how to deal with [.TESTLINK.-] in the same way that the GNV bash or the CRTL will do. The CRTL will have a new feature setting to indicate when the user has selected that UNIX style pathnames should be parsed in POSIX style, and while I can easily test for this in the C code, but it looks like I would need a way to let the .PM scripts know that this feature has been activated by the user in order to for the special cased OpenVMS code to work with symbolic links. Possibly. The perl absolute path routine is one of the ones that is affected by this as it is special cased for OpenVMS to do a manual parse of the filename. It calls VMS::Filespec::rmsexpand, which invokes mp_do_rmsexpand() in [.vms]vms.c. We could check for the feature involved here and omit the call to do_tovmsspec() in mp_do_rmsexpand() on the assumption that, as you seem to be implying above, sys$parse can handle unix syntax filenames when the symlink feature is available. There may be side effects and this would have to be studied carefully. sys$parse with the RMS SYMLINK kit will handle POSIX style names as long as they are prefixed with ^UP^ to identify them. So it is not automagically transparent. To have it return the real path name requires a qualifier to tell it not to work. And from a quick glance, this qualifier is only in the expanded NAML block. So it looks like if this were to be done at rmsexpand, there would need to be two versions of it, one where it was not supposed to reveal the contents of the symbolic link, and one where it does. And so far, it appears that it only one place requires the symbolic link be revealed. It looks like the way to do that is to have the affected scripts look up the setting of the DECC feature logicals while they run. If Perl is to support DECC$FILENAME_UNIX_ONLY and/or DECC$FILENAME_UNIX_REPORT, then yes, there will have to be some changes to various things and these will not be particularly easy changes. Historically, way back when the CRTL kinda sorta supported unix syntax filenames but often failed to handle them properly, the safest thing to do was just always convert to VMS syntax before calling the CRTL, and of course calls to system services and other RTLs have always had to do this as well. The Perl implementation is a very mixed bag of calls to the CRTL and to native APIs, so it might well be rather difficult to disentangle when we need unix syntax and when we need VMS syntax under conditions where we can no longer assume it's always safe to convert to VMS syntax. I agree, and this is something that will probably take a while to phase in. And the existing method of perl's operation should be the maintained and be the default. These feature logicals would only be set when someone specifically wanted to modify perl's behavior on VMS to pretend that it is UNIX. I have run into one problem with that so far though. In order for opendir()/readdir() to function correctly, I had to set the code to use the CRTL versions when the POSIX feature is on. This meant that I had to make the CRTL dirent and DIR structure used for OpenVMS
BUG: 5.8.6 IEEE float build support incomplete.
If you chose IEEE float, the build scripts do not set everything needed to build in IEEE floating point mode. Unless before running MMS/MMK before running Perl you have the equivalent of the CC command below set: $cc :== CC/FLOAT=IEEE/IEEE=DENORM Most of perl will be built for the default floating point for your platform. And this fails the self test is several places. The /IEEE=DENORM is required for all modules including a main() function and ignored on all others. In examining the descrip_mms.template, I see that the /FLOAT=IEEE/IEEE=DENORM is only used on some of the modules, and never used on the ones containing a main() routine. I tried one modification to pass a parameter for FFLAGS (FLOAT FLAGS) to the the script that modifies the descrip_mms.template, and this works for it, none of the other descrip.mms files picked up this change. It took redefining the CC command to get the floating tests to pass. I have not been able to figure out how to modify the scripts to have all the C Compiles to specify the /FLOAT=IEEE based on the configure.com script results. -John [EMAIL PROTECTED] Personal Opinion Only
5.8.6 - test lib/extutils/t/basic can not find mm.pm
I am trying to chase down some bugs in my last few test builds of perl. The test [.lib.extutils.t.basic] is failing because: ok 1 - chdir'd to Big-Dummy Can't locate ExtUtils/MM.pm in @INC (@INC contains: BFD_TEST_ROOT:lib ../lib lib) at lib/MakeMaker/Test/Utils.pm line 249. Now it appears to me that something was supposed to have created a [.t.lib.ExtUtils] directory and then copied mm.pm into it. I can not find where that create/copy is done or any message about it failing. -John [EMAIL PROTECTED] Personal Opinion Only
SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
The perl hack to produce a consistent dev_t st_dev will proably not work on symbolic links and mount points. So to support them I will have to make sure that the modules are built with the correct structure sizes. As the _USE_STD_STAT is likely to have the same order issues as _LARGEFILE did, it needs to be defined in the MMS files. Also, support for getpgid() will require that the feature macro __USE_LONG_GID_T be defined. It therefore looks like a change is needed to allow the configure script to pass a list of macros to be appended to a /define=() switch on the C compiler. If a harmless macro is specified in the MMS file for the cases where there are no extra macros to be defined, this would simplify the coding required to make this change That way the Configure script can do something that results in: BUILD_MACROS=,_LARGEFILE=1,_USE_STD_STAT=1,__USE_LONG_GID_T And where it is used: /MACRO=(VMS_NULL_ARG($)BUILD_MACROS) /MACRO=(X2SUBP($)BULD_MACROS) As I noted in my IEEE posting, I know how to make it work for the descrip_mms.tempate, but not the other generated descrip.mms files. -John [EMAIL PROTECTED] Personal Opinion Only
Re: 5.8.6 - test lib/extutils/t/basic can not find mm.pm
On Mon, 28 Feb 2005, Craig Berry wrote: On Monday, February 28, 2005, at 02:42PM, John E. Malmberg wrote: I am trying to chase down some bugs in my last few test builds of perl. The test [.lib.extutils.t.basic] is failing because: ok 1 - chdir'd to Big-Dummy Can't locate ExtUtils/MM.pm in @INC (@INC contains: BFD_TEST_ROOT:lib ../lib lib) at lib/MakeMaker/Test/Utils.pm line 249. As I recently posted, the 5.8.6 MakeMaker test failures were really the result of a bug in File::Spec (now part of the PathTools distribution). Don't waste your time on this, it's been fixed. If you are preparing a custom distribution, I recommend upgrading PathTools from CPAN. Ok, I pulled down the tarball. I just need to replace the files in that directory tree and do a build for just it? This looks like a module that I will need to modify to get symbolic links to work correctly. I need cwd to use realpath() when symbolic links are to be used or it will give the wrong answer if a when the default as been set to a directory path via a symbolic link. Thanks, -John [EMAIL PROTECTED] Personal Opinion Only
Re: BUG: 5.8.6 IEEE float build support incomplete.
On Mon, 28 Feb 2005, Craig Berry wrote: On Monday, February 28, 2005, at 02:16PM, John E. Malmberg wrote: If you chose IEEE float, the build scripts do not set everything needed to build in IEEE floating point mode. Yes, they do, but you don't need to choose anything. IEEE is the default on Alpha (and now Itanium) in Perl 5.8.0 and later. See the section entitled Floating Point Considerations in README.vms. I have looked at it. I also see that I made an error when I merged in your large file patch, and dropped the $(flags) for a couple of the build cases. which will revert to the compiler default. I believe the compiler flags we add for IEEE are redundant on Itanium, but it's easier to minimize the number of differences. You will still need /IEEE=DENORM, as that may not be the default. Ok, that's 2 out of three issues solved. Thanks, -John [EMAIL PROTECTED] Personal Opinion Only
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
Craig Berry wrote: On Monday, February 28, 2005, at 02:58PM, John E. Malmberg wrote: The perl hack to produce a consistent dev_t st_dev will proably not work on symbolic links and mount points. So to support them I will have to make sure that the modules are built with the correct structure sizes. As the _USE_STD_STAT is likely to have the same order issues as _LARGEFILE did, it needs to be defined in the MMS files. Also, support for getpgid() will require that the feature macro __USE_LONG_GID_T be defined. It therefore looks like a change is needed to allow the configure script to pass a list of macros to be appended to a /define=() switch on the C compiler. If a harmless macro is specified in the MMS file for the cases where there are no extra macros to be defined, this would simplify the coding required to make this change That way the Configure script can do something that results in: BUILD_MACROS=,_LARGEFILE=1,_USE_STD_STAT=1,__USE_LONG_GID_T I think CCDEFINES might be a better name, and I would prefer to make it a variable substitution on [.vms]descrip_mms.template rather than producing a long, complicated macro string that someone has to pass exactly right to MM(S|K). Annother option is to use the /FIRST_INCLUDE option. And where it is used: /MACRO=(VMS_NULL_ARG($)BUILD_MACROS) /MACRO=(X2SUBP($)BULD_MACROS) As I noted in my IEEE posting, I know how to make it work for the descrip_mms.tempate, but not the other generated descrip.mms files. If you modify the ccflags symbol appropriately (see what I did for uselargefiles), MakeMaker should pick it up from Config and use it to build extensions correctly. If I understand your uselargefiles change, you used a variable substitution for ~LARGEFILES~ and passed it as a parameter to the script that built the outer descrip.mms. I did not see a ccflags change, but I will look for it tomorrow. Did you get a chance to look at the hard link support modifications that I posted about? I am not sure how to resolve the issue on the test that fails. I think it is wrong for a test script to assume that the default protection would be PROT=(O:RWD, G:RWD, W:RWD). -John [EMAIL PROTECTED] Personal Opinion Only
Re: [.t.io]fs.t fails with hard links on OpenVMS.
On Tue, 1 Mar 2005, Craig A. Berry wrote:
At 4:31 PM -0600 2/23/05, John E. Malmberg wrote:
To be more precise,
The test [.t.io]fs.t will only pass when hard links {d_link} if you set
the default RMS protections to be (O:RW, G:RW, W:RW).
I think that it is a cross platform bug where the test is assuming such
a default protection would be in place.
I see a lot of mode setting. I think chmod on VMS sanely refuses to
override the RMS defaults with a less secure setting, but on Unix, an
explicit setting overrides the defaults if you have privilege to do
the chmod. Someone correct me if that's not right. Probably the
best thing to do for the test is create a temporary directory with
the necessary settings and set default to it before running the test.
the chmod() calls are below the test that failed. The umask calls
above the test succeed.
In the umask test, Perl makes two calls to umask(), one to set it to 022
with out paying attention to it's current value, and then again with
it restoring it to 0.
It appears that Perl through the CRTL or some other reason is treating a
umask of 0 as to use RMS default protection on the file.
The documentation for the CRTL shows that it should only be using the
RMS default for the umask call only if the umask call has never been made
for that program.
It looks like this needs some more investigation to find out why the
umask value of 0 is not being honored.
Also the modules utils/c2ph.pl, x2p/pl will not allow Perl to be built
with hard link support unless they are modified. They are trying to
create hard links from a different base filename than exists on OpenVMS.
I think something along the lines of the following untested patch
would be more appropriate. We've already got a platform-independent
version of the filename we're creating, so we might as well use it:
--- x2p/s2p.PL;-0 Mon Aug 12 07:28:26 2002
+++ x2p/s2p.PL Tue Mar 1 13:51:29 2005
@@ -2046,9 +2046,9 @@
close OUT or die Can't close $file: $!;
chmod 0755, $file or die Can't reset permissions for $file: $!\n;
unlink 'psed';
-print Linking s2p to psed.\n;
+print Linking $file to psed.\n;
if (defined $Config{d_link}) {
- link 's2p', 'psed';
+ link $file, 'psed';
} else {
unshift @INC, '../lib';
require File::Copy;
What do you need to have to get hard link support included in a future perl
release once the test issue is resolved? It looks like the problem in the
test is with umask handling and not hardlink related, which means that the
umask issue should be reproducible with out hard link support on.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
On Mon, 28 Feb 2005, Craig Berry wrote: I think CCDEFINES might be a better name, and I would prefer to make it a variable substitution on [.vms]descrip_mms.template rather than producing a long, complicated macro string that someone has to pass exactly right to MM(S|K). If you modify the ccflags symbol appropriately (see what I did for uselargefiles), MakeMaker should pick it up from Config and use it to build extensions correctly. If you specify more than one macro definition in ccflags the /DEFINE macros need to be in parenthesis. This causes the test lib/ExtUtils/t/Embed.t to fail because it passes the parenthesis back with an \ character in front of them to the DCL command. It turns out though, that I will only have one define, as _USE_STD_STAT implies _LARGEFILE and 32 bit GIDs, and symlinks will require _USE_STD_STAT. Based on your other post, I am modifying my copy of CONFIGURE.COM to enabling hardlinks if support is detected for them on the build disk, not as a build option. I am also only enabling SYMLINK support if the operating system supports it and the uselargefiles option is also active. -John [EMAIL PROTECTED]
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
Craig A. Berry wrote: At 8:26 AM -0600 3/3/05, John E. Malmberg wrote: It turns out though, that I will only have one define, as _USE_STD_STAT implies _LARGEFILE and 32 bit GIDs, and symlinks will require _USE_STD_STAT. Based on your other post, I am modifying my copy of CONFIGURE.COM to enabling hardlinks if support is detected for them on the build disk, not as a build option. Excellent. I look forward to your patch. I suppose there's no reason to do the check unless we're on v7.3-1 or later. At this time, I can only test it on v8.2, and v8.2 is the earliest that DCL can easily check to see if hard links are available. The lexical function to check if hard links are enabled on the hard drive starts with v8.2. For prior versions, either the output of $SHOW DEVICE/FULL would need to be parsed, or a temporary program written to do the test. What do you need for a patch to be submitted? I am also only enabling SYMLINK support if the operating system supports it and the uselargefiles option is also active. It may be counterintuitive that one has to enable large file support in order to also get symlink support. But I don't have a better suggestion at the moment. Actually there really should not be any reason not to enable large file support when it is available. There is a lot of work to get the symlink stuff working, because it also requires getting Perl to honor the DECC$FILENAME_UNIX_ONLY and DECC$FILENAME_UNIX_REPORT logical names every where it returns a filename. -John [EMAIL PROTECTED] Personal Opinion Only
Re: SYMLINK support needs _USE_STD_STAT like _LARGEFILE is defined.
Craig A. Berry wrote: At 11:40 PM -0500 3/3/05, John E. Malmberg wrote: Building an on-the-fly program, usually called try.c, is the standard way to go. There are quite a few examples in configure.com. There is no reason to even run the test on VAX or on non-VAX prior to v7.3-1. I will see about writing such a program for hard links being enabled, right now, I can only easily test it on 8.2. What do you need for a patch to be submitted? GNU unified diffs of any files that have changed would be ideal. It's not clear to me to what extent the various changes you have in progress can be separated out, but I'm willing to help with the separating if you have something we can go ahead and get into bleadperl. I'm assuming configure.com, [.vms]vmsish.h, and [.vms]descrip_mms.template at a minimum are involved. Actually as I posted before, there are two modules utils/c2ph.pl, x2p/pl, involved that you provided a better change to, and a change to configure.com to enable hard links. No changes to vmsish.h or descrip_mms.template are needed. It may be better to change the .PM modules so that for the VMS platform they can detect if hard links are available on the target, or detect that the link() call fails, they then fall back to the copy, and have the hard link test also skip that tests when hard links are not available. That way perl can be built with hard link support even on disks that do not support hard links. The only real outstanding issue for me with hard links is that the perl umask function is not working as expected, and this is only effectively tested if hard links are enabled. It looks like that perl test [.t.io]fs.t is wrong. It should be testing to see if the first file protection mask matches the what was set by the umask() call, even when hard links are not enabled. Then it should be checking to see that the triply linked file has the same umask as the original if hard links exist I probably will not have time to find out why the perl umask code is not working as expected for a little while as that appears to be an existing bug. It also appears that umask issues are present on other platforms as there are special case codes in the test. I will see what I can do to get some patches for bleadperl. Actually there really should not be any reason not to enable large file support when it is available. I think it's slower, and also we try to track whatever defaults the unix builds use. I do not see why it would be slower, it is probably just alternate inputs to the same I/O routines with larger data types for the transfers. Are the UNIX builds not auto-enabling large file support when they detect that it is available? -John [EMAIL PROTECTED] Personal Opinion Only
Re: ExtUtils::CBuilder on VMS (was Re: Phalanxing MakeMaker)
Ken Williams wrote: Care to try 0.09_01, which is now hitting CPAN? I've split out the generation of command-line switches so it can easily be overridden for VMS. So compile() might work now. link() and friends haven't been touched, though. When Perl is run in the GNV environment, it is likely that a future modification will be to have it use the Bash shell. The CC command when run under the BASH shell expects UNIX syntax. -John [EMAIL PROTECTED] Personal Opinion Only
5.8.6 - t/lib/vmsfspec.t missing from manifest.
It appears that the file t/lib/vmsfspec.t is missing from the manifest. file. Is there a perl script that will identify all files that are present in the unpacked directory except for the ones in the manifest or where generated by the build procedure? Also it appears that magic.t is leaving a logical name FOO behind so that if it is run before the INST_*.t tests, they fail as they are trying to create a file named FOO. When you use the MMS script to run the tests, they are run in a subprocess so this is not noticed. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Pathtool 3.05 breaks fail-like,fail-more and is_deeply
On Wed, 16 Mar 2005, John E. Malmberg wrote: Craig A. Berry wrote: I believe what he's done is taken Perl 5.8.6, merged PathTools 3.05 into it and run the core test suite. The before and after results he's showing are the core test suite results before and after upgrading PathTools. But without detailed results of what's failiing and why in the after case, I don't know if there's anything we can act on. What details do you need and how to I get them? The is_deeply test when I run it by it self is passing all 22 tests, however one test is generating some text explaining that it succeeded. That explanation is not being preceded by # characters like I have noticed on other tests. $ MCR Sys$Disk:[-]nDBGPerl -I[-.lib] [lib.test.simple.t]is_deeply.t 1..22 ok 1 - plain strings ok 2 - right diagnostic ok 3 - different types ok 4 -right diagnostic ok 5 - hashes with different values ok 6 -right diagnostic ok 7 - hashes with different keys ok 8 - right diagnostic ok 9 - arrays of different length ok 10 - right diagnostic ok 11 - arrays of undefs ok 12 - right diagnostic is_deeply() takes two or three args, you gave 4. This usually means you passed an array or hash instead of a reference to it at [lib.test.simple.t]is_deeply.t line 131 ok 13 - hashes of undefs ok 14 - right diagnostic ok 15 - scalar refs ok 16 - right diagnostic ok 17 - mixed scalar and array refs ok 18 - right diagnostic ok 19 - deep scalar refs ok 20 - right diagnostic ok 21 - deep structures ok 22 - right diagnostic -John [EMAIL PROTECTED] Personal Opinion Only
Re: Pathtool 3.05 breaks fail-like,fail-more and is_deeply
On Thu, 17 Mar 2005, Michael G Schwern wrote: On Thu, Mar 17, 2005 at 10:37:11AM -0600, John E. Malmberg wrote: The is_deeply test when I run it by it self is passing all 22 tests, however one test is generating some text explaining that it succeeded. That explanation is not being preceded by # characters like I have noticed on other tests. ok 12 - right diagnostic is_deeply() takes two or three args, you gave 4. This usually means you passed an array or hash instead of a reference to it at [lib.test.simple.t]is_deeply.t line 131 This is a warning which is supposed to be trapped by is_deeply.t so it can be tested. It has nothing to do with PathTools. Furthermore, that warning was added in Test::More 0.48_02. 5.8.6 shipped with 0.47. There are more changes to your 5.8.6 than simply upgrading PathTools. The file more.pm $VERSION = '0.49' was supplied with the Pathtools kit. This implies that I either need to use the older more.pm or I need a newer is_deeply to resolve this problem. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Pathtool 3.05 breaks fail-like,fail-more and is_deeply
On Thu, 17 Mar 2005, Michael G Schwern wrote: On Thu, Mar 17, 2005 at 01:45:31PM -0600, John E. Malmberg wrote: You'll notice that was in PathTool's [.t.lib] directory which does NOT normally get installed. It is there so that PathTools users do not have to upgrade or even install Test::More just to test PathTools. Do not copy the contents of t/lib when pulling a CPAN module into the core. Thanks for the help. I really am learning from this. Reverting back to those 4 modules fixed the is_deeply, and also the fail-like and fail-more tests. -John [EMAIL PROTECTED] Personal Opinion Only
Re: [PATCH] Module::Install 0.36 for VMS (was Re: Module::Install and portability?)
[Only monitoring vmsperl@perl.org for replies] Michael G Schwern wrote: On Sat, Mar 26, 2005 at 09:35:10AM -0600, Craig A. Berry wrote: 2.) Use '_author' instead of '.author' when on VMS since a dot in a directory name is usually invalid and always awkward. Really? I've yet to see a problem with .foo style on VMS. Where does it go wrong? It appears to go wrong in that the .foo/bar style of names is only supported on the ODS-5 filesystem and not ODS-2 and currently PERL on OpenVMS does not implement support for ODS-5. .foo as not a directory file is allowed with ODS-2, so such code does not need to be changed. The ODS-5 file system is only available on OpenVMS Alpha and I64. The current code to translate from VMS to UNIX and back file specifications is translating the extra dots in directory and filenames into _ characters, even when it should not, which is making some files on ODS-5 volumes invisible. In the stuff that I am testing for symbolic link support, I have implemented changes so that when translating an VMS specification with the extra dots to a UNIX style path, it will translate it correctly. It will also translate a UNIX style path with extra dots in it back to a VMS ODS-5 specification with out the dots being translated to _ if the SET PROC/PARSE=EXTENDED is set. I will not be implementing full ODS-5 support in this pass for VMS mode of filenames. If the mode is set to DECC$FILENAME_UNIX_ONLY after my changes, almost all UNIX file specifications should work on ODS-5 volumes. If it is a bad thing on VMS, MI should use _foo everywhere rather than create Yet Another VMS Exception. It will continue to be needed on directories for ODS-2 file system support. ODS-2 only allows 1 dot in a file specification and only if that file is not a directory. It also does not allow a directory specification to begin with a - character for most versions of OpenVMS that are currently be in use. Also with the stuff that I am doing for the symlink support, also the case sensitivity of perl on OpenVMS will reflect the state of the process setting, and not be hard coded to case insensitive. The resulting Perl on OpenVMS will properly pay attention to several of the DECC$ feature logicals as far as preserving case. The result should be that many Perl scripts that will not currently run on OpenVMS will run if the external mode controls are set appropriately. I am still debugging the changes needed for symbolic link support. -John [EMAIL PROTECTED] Personal Opinion Only
OpenVMS behavior options - (was: [ANNOUNCE] ExtUtils::MakeMaker 6.26_01)
[Replies set to vmsperl@perl.org, as it is the only list I am subscribed to]
Michael G Schwern wrote:
On Tue, Mar 29, 2005 at 02:43:42PM -0500, [EMAIL PROTECTED] wrote:
But in any case the tests all pass on VMS with or without that patch in place.
Now that's unexpected. VMS works but Solaris didn't.
Which makes this a point to bring up some VMSisms that some people
including OpenVMS Perl programmers may not be aware of.
There are also some changes that I am currently testing on the side that
will potentially affect any Perl module that has OpenVMS specific code
in it. They can be turned on and off as needed, but I would like to be
able to eventually pass the self tests supplied with Perl with these
features set.
MM_UNIX is one of the ones potentially affected. I am not yet good
enough at reading Perl scripts to tell.
Some background:
The behavior of the OpenVMS C runtime library is dependent on feature
logicals which control how many things work.
But with these feature logicals set, which perl scripts can check
through the ENV{} operator, the C RTL features of OpenVMS can change to
behaving more like UNIX and less like traditional OpenVMS.
The way that Perl is currently implemented, changing these feature
logicals from their default is almost certainly guaranteed to have bad
results. This is because in many cases some of the C filename parsing
is bypassed for the support of older versions of OpenVMS.
As part of what I am doing to implement Symbolic link support on
OpenVMS, it requires that to use Symbolic links, the C feature logicals
and VMS environment settings need to be honored by the PERL executable.
The plus side of this is that it will allow Perl on OpenVMS 8.2 (Alpha
and I64), and to a lesser extent older versions of OpenVMS on Alpha to
run many scripts that are expecting UNIX behavior that currently will
not run.
Many of these scripts are used in the building of programs on UNIX, and
having them work unmodified on OpenVMS would be goodness for all.
The unfortunate side effect is that when these features are set to a
UNIX compatible mode, any perl scripts that are expecting traditional
VMS behavior with out requesting a filename converted explicitly to VMS
format on VMS may break.
I hope that you will pardon my lack of Perl Script programing experience
on these explanations, and for brevity, I am simplifying things, but
some of the things that are optional are:
1. Treat all filenames as UNIX syntax. No VMS file specifications are
permitted.
2. Accept VMS or UNIX file specifications, but always report them as
UNIX type.
With either the above two enabled, the .dir on OpenVMS directories
vanishes from returned file specifications, which may be something that
impacts MM_UNIX as noted above. Also unless a VMS specific conversion
is requested, a returned file is likely to be in UNIX format and as
noted below in the correct case, and also may include UNICODE or other
characters that normally are not in a VMS file specification.
It certainly affects the standard tests that are supplied with Perl.
3. Case preserved filenames. Filenames will be created with the case
that the application specified them in and reported that way. This
requires that the files are on an ODS-5 file system or later.
This also affects the standard tests.
4. Case sensitive filenames. Unlike the others, this is not set by a
feature logical, but a VMS environment setting. I noticed in Perl that
it was able to inquire if a platform was case sensitive, and I changed
my local copy of Perl to report the process setting that is currently in
effect. I have not tested that mode yet. This also requires ODS-5
filesystem or later.
In my current development phase, these feature settings are only checked
at the startup of perl, and changing the ENV{} after that point may have
strange side effects.
There are some others, like the handling of umask() which can be
predicted or affected by the ENV{} for that value.
Also for the OpenVMS C runtime to effectively work with Symbolic links,
the option of 2 above needs to be set, and effectively at least the
option of 3 above also.
I have also noticed that some Perl scripts are assuming that / is a
directory separator for things like ENV{'HOME'} and 'PERL5DB'. When the
mode 1 or 2 above is set, those will work on OpenVMS, where now they do not.
-John
[EMAIL PROTECTED]
Personal Opinion Only
mm_vms.pm question.
In MM_VMS.PM, there is a comment that unixify will sometimes return a string with an off-by-one trailing null. And what does that mean? More than one null terminator? Do you have a reproducer for that problem? Thanks, -John [EMAIL PROTECTED] Personal Opinion Only
Re: 24318 warnes on OpenVMS V7.2
[only monitoring vmsperl list] Abe Timmerman wrote: Hi, I still can't build bleadperl on the VAX (without /ignore=warning): CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=GLOBALS.obj/NoList/ Define=PERL_CORE GLOBALS.C %VCG-W-BADPSECT, The program section(psect) specified by this statement has conflicting 'nowrite' attributes with another definition of the same program section. At line number 1002 in BLDROOT:[00]PERLAPI.H;1. That looks like a serious programming error, any idea what is causing it? It looks like it is saying that the same storage has been declared both as readonly and as writable at the same time. If this is VAX specific, it looks like something in an #ifdef VAX section is not coded correctly. -John [EMAIL PROTECTED] Personal Opinion Only
Re: 24318 warnes on OpenVMS V7.2
On Wed, 27 Apr 2005, Craig A. Berry wrote: At 12:58 AM -0400 4/27/05, John E. Malmberg wrote: [only monitoring vmsperl list] Abe Timmerman wrote: Hi, I still can't build bleadperl on the VAX (without /ignore=warning): CC/DECC /Include=[]/Standard=Relaxed_ANSI/Prefix=All/Obj=GLOBALS.obj/NoList/ Define=PERL_CORE GLOBALS.C %VCG-W-BADPSECT, The program section(psect) specified by this statement has conflicting 'nowrite' attributes with another definition of the same program section. At line number 1002 in BLDROOT:[00]PERLAPI.H;1. That looks like a serious programming error, any idea what is causing it? It looks like it is saying that the same storage has been declared both as readonly and as writable at the same time. More specifically, the likely cause would be something declared EXT in one place and EXTCONST elsewhere, which on VMS means globaldef and globaldef readonly, respectively. But the error message is less than helpful in identifying the problem since it points you to the last line in perlapi.h, well after any declarations. Nothing pops out in a quick look at Abe's listing file, but I'll try to dig into more later. Much of the time the line number is set to point to just before the next line that the compiler sees that generates code or data. You have to read backwards skipping all non-code or data generating pre-processor statements. I am noticing that in 5.8.6, EXTERN.H and INTERN.H have different definitions for EXTCONST that might produce that type of error message if they got mixed. At the moment I can not think of an DECC ANSI acceptable syntax to replace this usage of globalref/globaldef. In ANSI mode, I think that specifying the psect name requires a #pragma which needs to be on it's own line, but I would have to look that up to be sure. Also, check to see if the symbol readonly is being defined to something else, as I have encountered that as a problem on other open source products. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Anyone run vms/ext/filespec.t in a while?
Michael G Schwern wrote: I'm examining the feasibility of making VMS::Filespec available to all installations (makes testing File::Spec::VMS a whole lot easier) and ran vms/ext/filespec.t on my OS X box. I got some failures but none of them seem to be related to my running on Unix. They all appear to be genuine bugs in the code. So... has anyone run ext/vms/filespec.t on VMS in a while? Quite a bit, except for this past week while I am on vacation. It is producing incorrect answers when ODS-5 file specifications are in use. Other wise known as Extended File Specifications or EFS. Under ODS-5 file specifications, the UNIX path of ./.../foo should be translated to [.^.^.^.]foo. in VMS. Other translations that the script assumes should fail will not when translated to legal ODS-5 specifications. I think it was the one test script that I could not find an easy way to make work when the OpenVMS CRTL was working in a UNIX report or the comming Posix compliant pathname mode. Is anyone on this list using the test RMS Symbolic links SDK? I am going to have a lot of gnu diff files to post soon. Should I send them to this list an order that they can be applied harmlessly or put them all in a .ZIP archive somewhere? I had to do a lot of work in the Makemaker routines to get them to pass the tests when the OpenVMS CRTL is by default returning names in UNIX syntax instead of VMS. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Anyone run vms/ext/filespec.t in a while?
Michael G Schwern wrote:
On Fri, Jul 08, 2005 at 08:31:59PM -0400, [EMAIL PROTECTED] wrote:
I just ran it on IA64 with a perl 5.8.7 kit and it went ok:
Hmm. Here's the easiest of my failures to analyze:
not ok 52 - vmsify('.../'): '[]'
# Failed at ../vms/ext/filespec.t line 24
# got '[]'
# expected '[...]'
It also should be expected to return [.^.^.^] if the logical names
%ENV{$DECC$FILENAME_UNIX_REPORT} and %ENV{DECC$EFS_CHARSET} are defined
to 1 or their first letter is E or e
[.^.^.^.] is a legal directory on an ODS-5 volume.
-John
[EMAIL PROTECTED]
Personal Opinion Only
Re: Anyone run vms/ext/filespec.t in a while?
Michael G Schwern wrote:
On Sat, Jul 09, 2005 at 01:53:36AM -0400, John E. Malmberg wrote:
Hmm. Here's the easiest of my failures to analyze:
not ok 52 - vmsify('.../'): '[]'
# Failed at ../vms/ext/filespec.t line 24
# got '[]'
# expected '[...]'
It also should be expected to return [.^.^.^] if the logical names
%ENV{$DECC$FILENAME_UNIX_REPORT} and %ENV{DECC$EFS_CHARSET} are defined
to 1 or their first letter is E or e
[.^.^.^.] is a legal directory on an ODS-5 volume.
Missing the point. The point is I'm running different code on Unix than
you are on VMS.
I did not miss the point.
I am currently running different code on VMS than anyone else :-)
The QTV (internal OpenVMS Quality-Test-Verification) group has not
blessed it yet on IA64 for an unreleased version of OpenVMS that is also
in test.
I think I can start submitting some off the patches needed that will
likely be stable while getting the final issues resolved. Some of the
issues involve fixing a future CRTL.
vms/ext/Filespec.pm is out of date and broken.
And my point that you missed is:
So is Perl on OpenVMS when dealing with OpenVMS ODS-5 file
specifications. Filespec.pm is just more broken than the rest.
I am just giving a heads up in case that someone is working on fixing
Filespec.pm that even bringing it up to what is currently in the VMS C
source is still not going to make it correct.
What is probably needed is some way for VMS to be able to run
Filespec.pm with out the overrides from the extension present in the tests.
-John
[EMAIL PROTECTED]
Personal Opinion Only
VMS 8.2 change information (was: Anyone run vms/ext/filespec.t in a while?)
At 1:42 AM -0400 7/9/05, John E. Malmberg wrote: Is anyone on this list using the test RMS Symbolic links SDK? That's 8.2 only, right? I don't have any 8.2 systems, so unless it's on the testdrive I don't have anything available to experiment with. The SDK is for 8.2 only. It should only be deployed on test systems. I do not think it is on any of the test drive machines. I am going to have a lot of gnu diff files to post soon. Should I send them to this list an order that they can be applied harmlessly or put them all in a .ZIP archive somewhere? Yes, do send here. I think we'll want to kick them around a bit and test with slightly older versions of VMS, and we'll also need to see if any changes are necessary to get them to apply to bleadperl. Ok, I will start posting them to the list, a few at a time. I have a total of 49 diff files taking up 604 blocks. If someone wants them CC: to them in addition to the list, then I can do that too. These changes involve support for one combination of the DECC$FEATURE logicals for UNIX filename mode on existing VMS, and also the support of a new Posix compliant mode with symbolic links in a future VMS. They include a merge (to the best of my ability) of Pathtools 3.05 and other patches that I have been directed to by Craig and others on this list that I needed to implement these changes. -John
Hard link support for VMS (part 1)
These two files c2ph.pl and s2p.pl need to be updated for hard link
support before you can build perl on VMS for hard link support.
These files may be the only reason that building Perl on VMS with hard
link support requires it to be built on a disk with hard link support
enabled.
If a different change was made where if the link routine fails, a copy
is used instead, it may remove the above dependency, or it may expose
some other dependencies.
These were the ones that stopped my build until I fixed them and enabled
hard links on the build disk.
When perl is built on VMS with hard link support enabled, for the tests
to run successfully, the DECC$_FILE_PERMISSION_UNIX feature logical name
needs to be defined as ENABLE or one of the other values that the CRTL
will treat as equivalent.
I will post the diffs for the configure.com and descrip_mms.template next.
I also mis-counted on my previous post, I have a total of 54 files, 913
blocks.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- utils/c2ph.PL_5_8_6 Thu Feb 10 13:24:12 2005
+++ utils/c2ph.PL Wed Mar 9 15:07:20 2005
@@ -1435,9 +1435,9 @@
close OUT or die Can't close $file: $!;
chmod 0755, $file or die Can't reset permissions for $file: $!\n;
unlink 'pstruct';
-print Linking c2ph to pstruct.\n;
+print Linking $file to pstruct.\n;
if (defined $Config{d_link}) {
- link 'c2ph', 'pstruct';
+link $file, 'pstruct';
} else {
unshift @INC, '../lib';
require File::Copy;
--- x2p/s2p.PL_5_8_6Thu Feb 10 15:22:08 2005
+++ x2p/s2p.PL Tue Jun 14 16:30:23 2005
@@ -564,7 +564,13 @@
my $doAutoPrint = 1; # automatic printing of pattern space (-n = 0)
my $doOpenWrite = 1; # open w command output files at start (-a = 0)
my $svOpenWrite = 0; # save $doOpenWrite
-my $doGenerate = $0 eq 's2p';
+
+#lower case $0 below as a VMSism. The VMS build procedure creates the s2p file
+#in upper case, and in VMS mode, Perl returns it in lower case.
+#When VMS is in UNIX compatibility mode, Perl returns it in exact case
+#which could be either upper or lower, so make this test case tolerant.
+
+my $doGenerate = lc($0) eq 's2p';
# Collected and compiled script
#
@@ -2046,9 +2052,9 @@
close OUT or die Can't close $file: $!;
chmod 0755, $file or die Can't reset permissions for $file: $!\n;
unlink 'psed';
-print Linking s2p to psed.\n;
+print Linking $file to psed.\n;
if (defined $Config{d_link}) {
- link 's2p', 'psed';
+link $file, 'psed';
} else {
unshift @INC, '../lib';
require File::Copy;
Hard link support for VMS (part 2)
This configure.com tests to see if hard links are enabled on the build disk, and if so enables hard link support in the build. This test is only done on 8.2 even though hard links have been available since 7.3-1. 1. I only have been able to test with 8.2 and later at this time. 2. The dcl lexical function to test if hard links are enabled on a volume were implemented with 8.2 so a different test would be needed or the dependency removed. If someone needs hard link support for 7.3-1 or 7.3-2 it should not be too hard to add it. The MAKE now defaults to MMK if both MMK and MMS are present for the build as MMS currently has a problem with case preserved file types. If VMS is a 64 bit variant of 8.2 or later, many of the CRTL routines added in 7.3-2 are configured. This test could be brought back to 7.3-2, if someone were to do the testing. If VMS is a 64 bit variant of 8.2 or later, many of the CRTL routines added in 8.2 are now configured. If the uselargefiles option is selected and the realpath() routine exists in the CRTL, then support for symbolic links will be configured. The realpath() routine is in the RMS symbolic links SDK and is on the roadmap to be in a future version of VMS. Perl_setup.com is optionally built such that it defines perl_root based on the directory it currently resides in, as a step toward being able to build a binary distribution kit that does not require editing it. A number of patches from Craig and all for enabling builds on an ODS-5 volume with extra dots present. A number of fixes because of symbol conflicts when the symbol link may have been present before running the procedure. Latent support may be present for using the 8.2 standard stat() call. I had to back that out because VMS Perl is dependent on one field only provided by the existing non-standard stat() call. Once the resolution of a change for future VMS is more finalized, I hope to put that back in. Perl and the CRTL were incorrectly translating foo:[00] to be /foo/00/ instead of /foo. In order to get the UNIX mode to work, I had to fix this in the C source code. This also required configure.com to not add the 00/ to UNIX names that it created. -John [EMAIL PROTECTED] Personal Opinion Only --- configure.com_5_8_6 Mon Jan 31 14:17:14 2005 +++ configure.com Mon Jul 11 14:15:23 2005 @@ -32,12 +32,20 @@ $! the whole VMSPerl crew. $! Extended and messed about with by Dan Sugalski $! +$! J. Malmberg Implemented patches from Craig Berry for unlink_all_versions, +$!largefile support, and unpacking the kit with ODS-5 naming. +$! J. Malmberg Implemented symlinks and other features for 64 bit +$! OpenVMS 8.2. Protect LINK from symbol with debug qualifier. +$! J. Malmberg Implemented override selected builder/make from command line. +$! J. Malmberg Implemented use of 7.3-2 and 8.2 CRTL features for 8.2. +$! J. Malmberg Implemented patch from Craig Berry for buiding on I64. +$! $! VMS-isms we will need: $ echo = write sys$output $ cat = type $ delete := delete ! local symbol overrides globals with qualifiers $ gcc_symbol = gcc -$ ld = Link +$ ld = Link/nodebug $ ans = $ macros = $ extra_flags = @@ -45,9 +53,11 @@ $ use_ieee_math = y $ be_case_sensitive = n $ unlink_all_versions = n +$ builder = MMK $ use_vmsdebug_perl = n $ use64bitall = n $ use64bitint = n +$ uselargefiles = n $ C_Compiler_Replace = CC= $ Thread_Live_Dangerously = MT= $ use_two_pot_malloc = N @@ -510,7 +520,7 @@ $ file_2_find = file_2_find - dirname $! $! may not need double dot check on ODS-5 volumes -$ found = F$SEARCH(dirname + file_2_find) +$ found = F$SEARCH(dirname + file_2_find + ;0) $ IF found .NES. THEN GOTO Read_loop_manifest $! $ dots = 0 @@ -787,7 +797,12 @@ brackets; typing carriage return will give you the default. $ EOD +$ if (fastread) +$ then +$ echo4 +$ else $ READ SYS$COMMAND/PROMPT=Type carriage return to continue ans +$ endif $ TYPE SYS$INPUT: $ DECK @@ -797,7 +812,12 @@ options. $ EOD +$ if (fastread) +$ then +$ echo4 +$ else $ READ SYS$COMMAND/PROMPT=Type carriage return to continue ans +$ endif $ TYPE SYS$INPUT: $ DECK @@ -818,7 +838,12 @@ $!If you make a mistake on a question, there is no easy way to back up to it $!currently. $! +$ if (fastread) +$ then +$ echo4 +$ else $ READ SYS$COMMAND/PROMPT=Type carriage return to continue ans +$ endif $ IF (F$SEARCH([-.CONFIG]INSTRUCT.).EQS.) $ THEN $ OPEN/WRITE CONFIG [-.CONFIG]INSTRUCT. @@ -838,6 +863,7 @@ $! echo $! echo Don't worry if any of the following aren't found... $!: determine whether symbolic links are supported !sfn +$!: symbolic link check done later - J. Malmberg $!: see whether [:lower:] and [:upper:] are supported character classes !sfn $!: set up the translation script tr, must be called with ./tr of course !sfn $! @@ -881,7 +907,7 @@ $
Hard link support for VMS (part 3)
This descrip_mms.template mainly has changes that Craig Berry gave me for support of ODS-5 file specifications. I also changed the behavior of a DEBUG build to produce more useful listing files. The listing options should really be separated from the DEBUG option as a listing with machine code is useful to have for a non-debug build. There may be latent support present for using the standard stat structure. -John [EMAIL PROTECTED] Personal Opinion Only --- vms/descrip_mms.template_5_8_6 Tue Feb 1 15:57:22 2005 +++ vms/descrip_mms.templateTue Mar 8 17:34:45 2005 @@ -18,6 +18,8 @@ # cleansrc -- `realclean' + purge *.c,*.h,descrip.mms # crtl.opt -- compiler-specific linker options file (made automatically) # +# 09-Feb-2005 J. Malmberg Add Craig Berry largefile patch +# 24-Feb-2005 J. Malmberg Fix IEEE floating compile. Start of system configuration section. @@ -31,6 +33,7 @@ ~CC~ ~MT~ ~FLAGS~ +~LARGEFILE~ #: Architecture-specific options .ifdef IXE @@ -122,7 +125,16 @@ .else XTRAOBJS = LIBS1 = $(XTRAOBJS) -DBGSPECFLAGS = /Show=All +# +# FIXME: Listing control should be independent of debug settings. +# Listings are most useful when debugging code not built for +# debug. This should be a configure option. +#(over 1 GB of listing information) +#DBGSPECFLAGS = /Show=All + +# This is the worse case that I have ever needed. +DBGSPECFLAGS = /Show=(expansion,include)/machine + # Some versions of DECCRTL on AXP have a bug in chdir() which causes the change # to persist after the image exits, even when this was not requested, iff # SYSNAM is enabled. This is fixed in CSC Patch # AXPACRT04_061, but turning @@ -148,6 +160,11 @@ #: Configuration options #: __DEBUG__: builds images with full VMS debugger support +# +# FIXME: Listing control should be independent of debug settings. +# Listings are most useful when debugging code not built for +# debug. This should be a configure option. +# .ifdef __DEBUG__ DBGCCFLAGS = /List/Debug/NoOpt$(DBGSPECFLAGS) DBGLINKFLAGS = /Trace/Debug/Map/Full/Cross @@ -210,11 +227,15 @@ .endif # C preprocessor manifest DEBUGGING == perl -D, not the VMS debugger +.IFDEF LARGEFILE +CFLAGS = $(XTRACCFLAGS)$(DBGCCFLAGS)$(FLAGS)/Define=$(LARGEFILE) +X2PCFLAGS = $(XTRACCFLAGS)$(DBGCCFLAGS)$(FLAGS)/Define=(PERL_FOR_X2P,$(LARGEFILE)) +CORECFLAGS = $(XTRACCFLAGS)$(DBGCCFLAGS)$(FLAGS)/Define=(PERL_CORE,$(LARGEFILE)) +.ELSE CFLAGS = $(XTRACCFLAGS)$(DBGCCFLAGS)$(FLAGS) -# Flags for a core compile -X2PCFLAGS = $(CFLAGS)/Define=PERL_FOR_X2P -# Flags for an x2p compile -CORECFLAGS = $(CFLAGS)/Define=PERL_CORE +X2PCFLAGS = $(XTRACCFLAGS)$(DBGCCFLAGS)$(FLAGS)/Define=PERL_FOR_X2P +CORECFLAGS = $(XTRACCFLAGS)$(DBGCCFLAGS)$(FLAGS)/Define=PERL_CORE +.ENDIF LINKFLAGS = $(DBGLINKFLAGS) MAKE = $(MMS)
Documentation update - Readme.vms
This draft documentation is taylored for a perl to specifically go with the RMS Symbolic link test SDK, so may need some changes for other purposes. The specific information on about the Posix Compliant mode may change with the eventual VMS release that implements it. The Perl for the RMS Symbolic Link test kit has not yet finished QTV testing. -John [EMAIL PROTECTED] Personal Opinion Only --- README.vms_5_8_6Thu Jun 30 13:42:50 2005 +++ README.vms Fri Jul 1 16:12:43 2005 @@ -4,11 +4,160 @@ =head1 NAME -README.vms - Configuring, building, testing, and installing perl on VMS +README.vms - Configuring, building, testing, and installing Perl on VMS + +=head1 Special HP Symbolic Link test Perl information + +This HP SYMBOLIC LINK SDK test release of Perl is a demonstration kit +for evaluation and testing of using the new RMS support for POSIX +Compliant Pathnames, and symbolic links. + +Some of the features in the SYMBOLIC LINK SDK may be different than what +will eventually be provided as part of the OpenVMS operating system. + +The Perl source kit for the SDK provides an additional command procedure +that can recreate the distributed binaries. + +It is an test demonstration kit for evaluating the new RMS Symbolic Link +features and better UNIX compatibility. + +The HP supplied test demonstration binary Perl kit can only be used with +systems that have the RMS Symbolic link SDK kit installed. + +The HP supplied test demonstration Perl Binary Kit is built with the +following options: unlink_all_versions and uselargefiles. + +Currently this test version of Perl for OpenVMS is distributed by BACKUP +SAVE SETS that may be compressed in ZIP archives, as the INFO-ZIP program +on OpenVMS does not fully support the extended file specifications on ZIP +archives that it creates. + +This saveset is intended to be installed on ODS-5 volumes, but also has +additional copies of some files with names changed to be compatible with +scripts that assume ODS-2 restrictions. + +The saveset names will be in PCSI convention so will be similar to +HP-*VMS-PERL-T0508-06*-1.BCK and HP-VMS-PERL_SRC-T0508-06*-1.BCK. + +To install, chose the physical or concealed rooted logical disk that you +want to install on and do a normal restore, for example + + BACKUP HP_AXPVMS-PERL-T0508-06-1.BCK/SAV device:[*...] + +Then use the command @device:[HP_PERL_5_8_6]PERL_SETUP.COM to your +LOGIN.COM in order to have the Perl logicals and symbols defined. + +=head2 Usage of new features in this test version of Perl + +This test version of Perl has improved support for ODS-5 volumes. + +To enable improved support for ODS-5, you need to activate the CRTL +feature. + + $DEFINE DECC$EFS_CHARSET ENABLE + +There is now optional support for case preserved file specifications. + + $DEFINE DECC$EFS_CASE_PRESERVE ENABLE + +If the running process is set to case sensitive mode, Perl will also +be case sensitive on VMS and will report it. Running a process in +case sensitive mode with out enabling case preserved file specifications, +will probably not work very well. At this time, the case sensitive mode +has not been tested. + +To enable case sensitive mode: + + $SET PROCESS/CASE_LOOKUP=SENSITIVE + + +This test version of Perl has two optional UNIX/POSIX compatibility modes +that are enabled by DECC feature logicals. + +To enable a mode where pathnames will be output as UNIX in the close to the +traditional CRTL format: + + $DEFINE DECC$EFS_CASE_PRESERVE ENABLE + $DEFINE DECC$EFS_CHARSET ENABLE + $DEFINE DECC$FILENAME_UNIX_NO_VERSION ENABLE + $DEFINE DECC$READDIR_DROPDOTNOTYPE ENABLE + $DEFINE DECC$FILENAME_UNIX_REPORT ENABLE + +To enable a mode where pathnames will be output as POSIX and the symbolic +link function, use the same logical names as before and add: + + $DEFINE DECC$POSIX_COMPLIANT_PATHNAMES 3 !Ambiguous names presumed VMS + +For this test version of Perl and the RMS Symbolic link SDK, the following +logicals are also needed to temporarily work around issues in POSIX handling. + + $!Special case for mkdir/chdir/rmdir/opendir treating a directory name + $!with no with no path or type delimiters only as a VMS logical name when + $!DECC$POSIX_COMPLIANT_PATHNAMES is defined a 3. + + $DEFINE DECC_DIR_BARENAME ENABLE + + $! Readdir in DECC$READDIR_UNIX_REPORT mode escaping EFS characters + $! in SDK CRTL + + $DEFINE DECC_BUG_READDIR_EFS1 ENABLE + + $! POSIX compliance mode requires a /dev/null be created. + $! The RMS Symbolic link SDK will create one. + $! If you do not want to use it, as a temporary work around + + $! DEFINE DECC_BUG_DEVNULL ENABLE + + $! The SDK CRTL realpath() is not working on pathnames that are a + $! symbolic link with no UNIX or VMS directory or file type delimiters. + $! Perl has a bsd_realpath function that can be used as a fallback, + $! but it is significantly slower. + + $! DEFINE DECC_DISABLE_CRTL_REALPATH + +=head2 Known BUGS + +The change directory
Documentation update - perlvms_pod
This draft documentation is taylored for a perl to specifically go with the RMS Symbolic link test SDK, so may need some changes for other purposes. The specific information on about the Posix Compliant mode may change with the eventual VMS release that implements it. The Perl for the RMS Symbolic Link test kit has not yet finished QTV testing. And this has probably given everyone enough reading for the moment, so it is my last direct sending today. -John [EMAIL PROTECTED] Personal Opinion Only --- vms/perlvms.pod_5_8_6 Thu Jun 30 15:36:37 2005 +++ vms/perlvms.pod Fri Jul 1 15:51:08 2005 @@ -6,7 +6,7 @@ Gathered below are notes describing details of Perl 5's behavior on VMS. They are a supplement to the regular Perl 5 -documentation, so we have focussed on the ways in which Perl +documentation, so we have focused on the ways in which Perl 5 functions differently under VMS than it does under Unix, and on the interactions between Perl and the rest of the operating system. We haven't tried to duplicate complete @@ -121,11 +121,11 @@ IN.B. The procedure by which extensions are built and tested creates several levels (at least 4) under the directory in which the extension's source files live. -For this reason if you are runnning a version of VMS prior +For this reason if you are running a version of VMS prior to V7.1 you shouldn't nest the source directory too deeply in your directory structure lest you exceed RMS' -maximum of 8 levels of subdirectory in a filespec. (You -can use rooted logical names to get another 8 levels of +maximum of 8 levels of subdirectory in a file specification. +(You can use rooted logical names to get another 8 levels of nesting, if you can't place the files near the top of the physical directory structure.) @@ -194,12 +194,141 @@ interconversion between VMS and Unix syntax; its documentation provides more details. -Filenames are, of course, still case-insensitive. For -consistency, most Perl routines return filespecs using -lower case letters only, regardless of the case used in -the arguments passed to them. (This is true only when -running under VMS; Perl respects the case-sensitivity -of OSs like Unix.) +With this test version of Perl, Perl now generally follows the +setting of the DECC$* feature logicals in the interpretation +of UNIX pathnames. + +Except for handling extended characters, and case sensitivity, as +long as DECC$POSIX_COMPLIANT_PATHNAMES, DECC$FILENAME_UNIX_REPORT, +and DECC$FILENAME_UNIX_ONLY are not set, then the older +perl behavior for conversions of file specifications from UNIX +to VMS is followed, except that VMS paths with concealed rooted +logicals are now translated correctly to UNIX paths. + +With those features set, then new routines handle the translation, +because some of the rules are different. The presence of ./.../ +in a UNIX path is no longer translated to the VMS [...]. It will +translate to [.^.^.^.]. To be compatible with what MakeMaker expects, +if a VMS path can not be translated to a UNIX path when unixify +is called, it is passed through unchanged. So unixify([...]) will +return [...]. + +The RMS Symbolic Link SDK also introduces a new ^UP^posix/pathname/file +syntax that most VMS routines will accept. This test version of Perl +has modified to understand it when the DECC$POSIX_COMPLIANT_PATHNAMES +feature is enabled. + +The handling of extended characters will also be better in with the +newer translation routines. But more work is needed to fully support +extended file syntax names. + +There are several ambiguous cases where a conversion routine can not +determine if an input filename is in UNIX format or in VMS format, +since now both VMS UNIX file specifications can have characters in +them that could be mistaken for syntax delimiters of the other type. +So some pathnames simply can not be used in a mode that allows either +type of pathname to be present. + +Perl will tend to assume that an ambiguous filename is in UNIX format. + +Allowing . as a version delimiter is simply incompatible with +determining if a pathname is already VMS format or UNIX with the +extended file syntax. There is no way to know if perl-5.8.6 that +TAR produces is a UNIX perl-5.8.6 or a VMS perl-5.8;6 when +passing it to unixify() or vmsify(). + +The DECC$FILENAME_UNIX_REPORT or the DECC$FILENAME_UNIX_ONLY logical +names control how Perl interprets filenames. + +The DECC$FILENAME_UNIX_ONLY setting has not been tested at this time. +Perl uses traditional OpenVMS file specifications internally and in +the test harness, so this mode may have limited use, or require more +changes to make usable. + +Everything about DECC$FILENAME_UNIX_REPORT should be assumed to apply +to DECC$FILENAME_UNIX_ONLY mode. The DECC$FILENAME_UNIX_ONLY differs +in that it expects all filenames passed to the C runtime to be already +in UNIX format. + +The logical name DECC$POSIX_COMPLIANT_PATHNAMES is new with the +RMS Symbolic
Re: Hard link support for VMS (part 2)
Craig A. Berry wrote: John, Thanks for all your good work on this. I've sprinkled in a few comments below, but it shouldn't be too tough to get this work incorporated into the authoritative sources, though I can't make any promises about when that will happen. There are a few projects that I am aware of that require a Perl running on VMS to act more like it is on UNIX, and it is not likely those Perl scripts will be modified to be platform independent. So it is likely that HP will need to put out a Perl with this behavior before the authoritative sources are updated. What I am hoping for is to for these and the others I will be posting later get merged in. And as my Perl programming skills are still at a very introductory level, there may be better ways of implementing what I have done. At 6:43 PM -0400 7/11/05, John Malmberg wrote: This configure.com tests to see if hard links are enabled on the build disk, and if so enables hard link support in the build. @@ -1480,7 +1506,7 @@ $ IF F$TYPE(archlib).EQS. THEN - archlib=''vms_prefix':[lib.''archname'.''version'] $ IF F$TYPE(bin) .EQS. THEN - - bin=/''vms_prefix'/00 + bin=/''vms_prefix' $ IF F$TYPE(privlib) .EQS. THEN - privlib =''vms_prefix':[lib] $ IF F$TYPE(sitearch) .EQS. THEN - I think this needs to be the unixy equivalent of perl_root:[00]. So are you saying that when we translate /perl_root to VMS syntax, that's what we'll now get? From what I can see of the existing code, that is the way it always should have worked. Perl already knew that /perl_root = PERL_ROOT:[00]. The extra /00 was causing me problems with converting the UNIX name back to a VMS name in the new UNIX and Posix Compliant modes, as some of the routines know to remove it, and some do not. And if you pass a UNIX name with that extra /00 in it directly to a CRTL routine or to the GNV environment, it will not work. @@ -1595,7 +1621,7 @@ $ ENDIF $ ELSE $ IF (F$LOCATE(DEC,line).NE.F$LENGTH(line)).or.(F$LOCATE(Compaq,line).NE.F$LENGTH(line)) - -.or.(F$LOCATE(hp,line).NE.F$LENGTH(line)) +.or.(F$LOCATE(HP,F$EDIT(line,UPCASE)).NE.F$LENGTH(line)) Same or similar patch is already in. I would expect so, I got that one from your post on this list. But my differences are to what was kitted with Perl 5.8.6. +$ rp = Try to understand large files, if available? [''bool_dflt'] Large file support is already in, so for this to be applied, we will have to sort out what's new. I do not know why that is showing up as a change. Perhaps DIFF is confused, or I made a whitespace change unintentionally. +$ IF (tmp .GES. 8.2) .AND. (f$getsyi(HW_MODEL) .GE. 1024) Last time I checked, Itanium systems return zero for f$getsyi(HW_MODEL). The archname symbol should already have one of VMS_VAX, VMS_AXP, or VMS_IA64, and the vms_ver symbol should already have the VMS version. I think I checked this on an Itanium system. The Itanium systems start at a higher range than Alpha, and the VAXen are from 0 to 1023. I will check again tomorrow. In many cases, what is needed is to know if this is a 32 bit platform or 64 bit as Alpha and Itanium share a common source base. Checking the VMS version lexical can be problematic when you are working with unreleased versions of VMS. I also noticed that some symbols get overwritten, so I copied an existing section of code in configure.com that was using tmp for that symbol just to make sure that it worked. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Hard link support for VMS (part 2)
Craig A. Berry wrote: At 6:43 PM -0400 7/11/05, John Malmberg wrote: Perl_setup.com is optionally built such that it defines perl_root based on the directory it currently resides in, as a step toward being able to build a binary distribution kit that does not require editing it. It has bothered me for a long time that we create a perl_setup.com that cannot be distributed and used as a smart set-up procedure that deduces its own location and sets perl_root accordingly. When I distribute binaries, I do this, but it's not in the core for the following reason. The problem with creating a smart perl_setup.com is that the installperl script, via the install target in [.vms]descrip_mms.template, uses it to figure out the target installation directory. So if we have a self-locating perl_setup.com, we'll just be installing on top of the source directory. Probably the right thing to do is rewrite the install target so it does not depend on perl_setup.com to know where it's installing. Yep, I encountered that too. If you look at the Perl_setup.com that is optionally generated, if that same logical name is present that triggers the optional Perl_setup.com, it also inhibits Perl_setup.com from overriding the logical name Perl_root in when the install step is done. There are other things that need to be set at installation time that Perl is currently setting at build time. Things like the contact information and e-mail addresses. Also it appears that some want Perl to report the current OS version instead of the OS version that Perl was built on or installed on. By default Perl reports the OS version that Perl was built on. -John [EMAIL PROTECTED] Personal Opinion Only
Re: Hard link support for VMS (part 3)
Craig A. Berry wrote: At 6:48 PM -0400 7/11/05, John Malmberg wrote: This descrip_mms.template mainly has changes that Craig Berry gave me for support of ODS-5 file specifications. I believe you mean files over 2GB via the _LARGEFILE definition, and unless I'm even dottier than I think I am, support for this has already been checked into the core and is available in 5.8.7. Correct. Remember my diffs are against the perl 5.8.6 release. Is 5.8.7 a release kit now? I also changed the behavior of a DEBUG build to produce more useful listing files. When /show=all was first added, it didn't do nearly as much as it does now, so yes, it's a bit more verbose than most folks would need. The listing options should really be separated from the DEBUG option as a listing with machine code is useful to have for a non-debug build. Well, it's trivial to add whatever you want to extra_cc_flags at configure time. I'm not sure I see a reason to more configuration options to handle specific listing preferences. Of course you have to know what options are there. I do not know the configure process to that detail. What I usually do is just change the symbols for the CC and LINK commands for what listing options that I need. Having the /NOLIST explicitly in the .MMS script foils that trick. And what I have accomplished is mainly because I got assistance from you and the others on this mailing list. -John [EMAIL PROTECTED] Personal Opinion Only
cwd.t changes for UNIX/POSIX/symbolic links
This difference listing shows how I am checking the DECC feature
logicals to so that the Perl script will handle pathnames in the same
way that the CRTL has been told to.
It is against the 5.8.7 perl as I had to install the pathtool patch on
Perl 5.8.6 which is now part of 5.8.7.
Use of some of the DECC$ feature logicals that I have in these patches
may not work properly until all the patches that I have are installed.
However using those same feature logicals now on the Perl from CPAN with
out any of my patches is probably also not going to work in the same way.
So these patches should be able to be applied to a bleadperl in advance
of the entire set being applied.
I am not doing the value check of the logical names exactly the same as
the CRTL. While the CRTL is more liberal on what it will accept for an
ENABLE setting, HP recommends that the string ENABLE be used on
them. So this is how
The DECC$POSIX_COMPLIANT_PATHNAMES is active with a value from 1 to 4,
where 4 is a special mode that disallows UNIX names being passed to the
CRTL. I do not see 4 as a valid mode to run Perl in. And this value
range is still subject to change.
Currently mode 0 (or undefined) or mode 3 is the only one that will work
with the Symbolic Link SDK.
If you do not have the symbolic link SDK, then there is no reason for
this logical name to be defined.
But that is why I an checking for non-zero, and not 3.
The DECC$FILENAME_UNIX_ONLY means that the CRTL assumes that all
pathnames given to it will be UNIX. So it will treat X:[FOO]BAR as
the VMS file specification []X^:^[FOO^]BAR.. I do not see this as a
useful mode of running Perl, but am putting in the foundation of this
just in case someone else wants to complete the job.
The DECC$FILENAME_UNIX_ONLY also implies DECC$FILENAME_REPORT_UNIX.
In DECC$FILENAME_UNIX_REPORT mode, the CRTL will default to returning
UNIX specifications, but still will accept VMS ones. Of course
sometimes it is not possible to detect the difference, and on an ODS-5
volume, the UNIX Perl.5.8.7 can exist as [.Perl^.5^.8^.7].
Many of the Perl scripts needed modifications based on what the DECC$
feature logicals implied.
One of the things I have discovered is that in the UNIX_REPORT modes,
Perl seems to be able to find the GNV components when they are installed
and tries to use them in the tests. Unfortunately if there is a
conflicting DCL verb, the results may be not what you expect.
In this case, the GNV pwd command is the quickest way I have to get the
current working directory in a UNIX format outside of Perl.
In debugging this case, I discovered that Perl on VMS is depending on
the CRTL accepting a previously invalid pathname to the chdir() routine.
Perl is passing that argument with leading spaces.
Leading spaces are valid in filenames on ODS-5 volumes, so in a UNIX
mode, chdir foo would be expected to do a change dir to [.^_^_foo].
In order to keep from having to find all the perl scripts that are
taking the output of SHOW DEFAULT or equivalent with out trimming the
spaces, I have modified the chdir() in VMS.C to trim the leading spaces
off. [I may have forgotten to put this in a readme file]
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- ext/Cwd/t/cwd.t_5_8_6 Mon Mar 14 15:25:16 2005
+++ ext/Cwd/t/cwd.t Wed Jun 15 15:19:11 2005
@@ -1,31 +1,64 @@
-#!./perl
+#!./perl -w
BEGIN {
-chdir 't' if -d 't';
if ($ENV{PERL_CORE}) {
+chdir 't';
@INC = '../lib';
}
}
use Cwd;
+chdir 't';
-use Config;
use strict;
-use warnings;
+use Config;
use File::Spec;
use File::Path;
+use lib File::Spec-catdir('t', 'lib');
use Test::More;
+require VMS::Filespec if $^O eq 'VMS';
-my $tests = 24;
-my $EXTRA_ABSPATH_TESTS = $ENV{PERL_CORE} || $ENV{TEST_PERL_CWD_CODE};
+my $tests = 28;
# _perl_abs_path() currently only works when the directory separator
# is '/', so don't test it when it won't work.
-$EXTRA_ABSPATH_TESTS = $Config{prefix} =~ m/\//;
-$tests += 3 if $EXTRA_ABSPATH_TESTS;
+my $EXTRA_ABSPATH_TESTS = ($Config{prefix} =~ m/\//) $^O ne 'cygwin';
+$tests += 4 if $EXTRA_ABSPATH_TESTS;
plan tests = $tests;
+SKIP: {
+ skip no need to check for blib/ in the core, 1 if $ENV{PERL_CORE};
+ like $INC{'Cwd.pm'}, qr{blib}i, Cwd should be loaded from blib/ during
testing;
+}
+
my $IsVMS = $^O eq 'VMS';
my $IsMacOS = $^O eq 'MacOS';
+my $posix_compliant;
+my $unix_report;
+my $unix_only;
+
+if ($IsVMS) {
+$posix_compliant = $ENV{'DECC$POSIX_COMPLIANT_PATHNAMES'};
+if (defined $posix_compliant) {
+ if (($posix_compliant lt '1') ($posix_compliant ne 'ENABLE')) {
+ $posix_compliant = undef;
+ }
+}
+$unix_report = $ENV{'DECC$FILENAME_UNIX_REPORT'};
+if (defined $unix_report) {
+ if (($unix_report lt '1') ($unix_report ne 'ENABLE')) {
+ $unix_report = undef;
+ }
+}
+$unix_only = $ENV{'DECC$FILENAME_UNIX_ONLY'};
+if
ext/file/glob/t/basic.t and ext/posix/t/posix.t changes.
These diffs are against 5.8.7.
Essentially allow these test to be run in a UNIX emulation mode.
For the 64 bit OpenVMS, what really needs to be done is that all the
test scripts need to be run in the default mode, and then in a UNIX
REPORT mode, and when the future VMS comes out with the POSIX mode, a
third time.
Of course if the UNIX ONLY mode is implemented, then there will
eventually be two flavors of that, POSIX and traditional.
Of course if you make a matrix of all the current possible ways that the
CRTL can be told to interpret a UNIX pathname, it would take quite a
large number of test runs to cover all of them, assuming that Perl and
the test modes were changed to handle them also.
For now, I am sticking a bunch of features that result in pathnames by
default being reported as UNIX format, with support for the future
POSIX mode that assumes pathnames are VMS if they are ambiguous.
This is probably enough new topics for today.
-John
[EMAIL PROTECTED]
Personal Opinion Only
--- ext/File/Glob/t/basic.t_5_8_7 Tue Jul 12 17:44:21 2005
+++ ext/File/Glob/t/basic.t Tue Jul 12 17:53:02 2005
@@ -111,20 +111,70 @@
}
print ok 7\n;
+# VMS can pretend it is UNIX.
+
+my $IsVMS = $^O eq 'VMS';
+my $posix_compliant;
+my $unix_report;
+my $unix_only;
+my $case_preserved = 1;
+my $vms_drop_dot;
+my $vms_format = 0;
+if ($IsVMS) {
+$vms_format = 1;
+$posix_compliant = $ENV{'DECC$POSIX_COMPLIANT_PATHNAMES'};
+if (defined $posix_compliant) {
+ if (($posix_compliant lt '1') ($posix_compliant ne 'ENABLE')) {
+ $posix_compliant = undef;
+ }
+}
+$unix_report = $ENV{'DECC$FILENAME_UNIX_REPORT'};
+if (defined $unix_report) {
+ if (($unix_report lt '1') ($unix_report ne 'ENABLE')) {
+ $unix_report = undef;
+ }
+}
+$unix_only = $ENV{'DECC$FILENAME_UNIX_ONLY'};
+if (defined $unix_only) {
+ if (($unix_only lt '1') ($unix_only ne 'ENABLE')) {
+ $unix_only = undef;
+ }
+}
+$unix_report = 1 if (defined $unix_only);
+
+$case_preserved = $ENV{'DECC$EFS_CASE_PRESERVE'};
+if (defined $case_preserved) {
+ if (($case_preserved lt '1') ($case_preserved ne 'ENABLE')) {
+ $case_preserved = undef;
+ }
+}
+$vms_drop_dot = $ENV{'DECC$READDIR_DROPDOTNOTYPE'};
+if (defined $vms_drop_dot) {
+ if (($vms_drop_dot lt '1') ($vms_drop_dot ne 'ENABLE')) {
+ $vms_drop_dot = undef;
+ }
+}
+if ((defined $unix_report) (defined $vms_drop_dot)) {
+ $vms_format = 0
+}
+}
+
@a = bsd_glob(
'{TES*,doesntexist*,a,b}',
-GLOB_BRACE | GLOB_NOMAGIC | ($^O eq 'VMS' ? GLOB_NOCASE : 0)
+GLOB_BRACE | GLOB_NOMAGIC | (!(defined $case_preserved) ? GLOB_NOCASE : 0)
);
# Working on t/TEST often causes this test to fail because it sees Emacs temp
# and RCS files. Filter them out, and .pm files too, and patch temp files.
@a = grep !/(,v$|~$|\.(pm|ori?g|rej)$)/, @a;
[EMAIL PROTECTED] = (grep !/test.pl/, @a) if $^O eq 'VMS';
+if (($^O eq 'VMS') !(defined $unix_report)) {
+@a = (grep !/test.pl/, @a);
+}
print # @a\n;
unless (@a == 3
-and $a[0] eq ($^O eq 'VMS'? 'test.' : 'TEST')
+ and $a[0] eq ($vms_format ? 'test.' : 'TEST')
and $a[1] eq 'a'
and $a[2] eq 'b')
{
@@ -150,7 +200,8 @@
if ('a' lt 'A') { # EBCDIC char sets sort lower case before UPPER
@f_names = sort(@f_names);
}
-if ($^O eq 'VMS') { # VMS is happily caseignorant
+# VMS is normally happily caseignorant
+if (($^O eq 'VMS') !(defined $case_preserved)) {
@f_alpha = qw(ax.pl ay.pl bx.pl by.pl cx.pl cy.pl);
@f_names = @f_alpha;
}
--- ext/Posix/t/posix.t_5_8_7 Tue Jul 12 17:57:55 2005
+++ ext/Posix/t/posix.t Tue Jul 12 17:58:09 2005
@@ -28,6 +28,34 @@
$Is_UWin= $^O eq 'uwin';
$Is_OS390 = $^O eq 'os390';
+# VMS can pretend it is UNIX.
+my $posix_compliant;
+my $unix_report;
+my $unix_only;
+if ($Is_VMS) {
+$posix_compliant = $ENV{'DECC$POSIX_COMPLIANT_PATHNAMES'};
+if (defined $posix_compliant) {
+ if (($posix_compliant lt '1') ($posix_compliant ne 'ENABLE')) {
+ $posix_compliant = undef;
+ }
+}
+$unix_report = $ENV{'DECC$FILENAME_UNIX_REPORT'};
+if (defined $unix_report) {
+ if (($unix_report lt '1') ($unix_report ne 'ENABLE')) {
+ $unix_report = undef;
+ }
+}
+$unix_only = $ENV{'DECC$FILENAME_UNIX_ONLY'};
+if (defined $unix_only) {
+ if (($unix_only lt '1') ($unix_only ne 'ENABLE')) {
+ $unix_only = undef;
+ }
+}
+$unix_report = 1 if (defined $unix_only);
+}
+
+
+
ok( $testfd = open(TEST, O_RDONLY, 0),'O_RDONLY with open' );
read($testfd, $buffer, 4) if $testfd 2;
is( $buffer, #!./, 'with read' );
@@ -128,7 +156,7 @@
if ($Is_MacOS) {
$pat = qr/:t:$/;
}
-elsif ( $Is_VMS ) {
+elsif ( $Is_VMS !(defined $unix_report)) {
$pat = qr/\.T]/i;
}
else {
Re: Hard link support for VMS (part 2)
[EMAIL PROTECTED] wrote: At 6:43 PM -0400 7/11/05, John Malmberg wrote: Perl_setup.com is optionally built such that it defines perl_root based on the directory it currently resides in, as a step toward being able to build a binary distribution kit that does not require editing it. I'd recommend writing a perl script or DCL procedure that does the editing. At the very least make the relocatable perl_setup.com a non default option offered by configure.com. It is implemented as a slightly hidden non-default option. For CGI scripts and other advanced setups obviously there are better ways of doing it, by using the JOB, GROUP, SYSTEM or custom tables. I just discovered that the *.OPT files in the build directory have absolute pathnames in then, and the ones in the directory created by the install step have absolute files. It gets me curious of why not simply use logical names in the option files, and use $define/user or $define in the build procedure. -John [EMAIL PROTECTED] Personal Opinion Only
