At 11:37 PM -0400 4/11/04, John E. Malmberg wrote: > >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.
Meaning these were already there in your environment? Or that the GTK+ build requires them independently? >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. Specifically, MakeMaker's comparison of manifests with names retrieved from the filesystem needs to be case blind when case may be preserved, as logged in the following ticket: http://rt.cpan.org/NoAuth/Bug.html?id=2746 > As I understand it, neither Craig or I know if that catches all > the instances where Perl is forcing things to lower case. There's probably not much else in the core, but I wouldn't be surprised if there are extensions out there that make similar assumptions. >* 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. What if it could honor the feature setting instead of needing to disable it? In fact it seems that is what you are doing when you allow "." to mean the current directory. > 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. Your patch should be fine here since it leaves _NLA0: for folks on older systems (with CRTLs that don't know about /dev/null). >* 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. It's just returning the value of the DEFAULT logical name. It should be easy enough to make it run the result through VMS::Filespec::unixify if DECC$FILENAME_UNIX_REPORT is in effect. >* 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. Hmm. What does the lie look like? >* 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. The Perl idiom to delete all versions of a file is to say 1 while unlink 'file.dat'; But as far as making it always delete all versions, I think you are right a run-time option is better. >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. Hmm. I can't reproduce that with either the GNU diff from Freeware 5.0 nor the one in GNV. >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. Could well be. >With the above tests, I have not patched the *.pm modules. > >The configure.com script was invoked with: > >$ @DIST_ROOT:[000000]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. I think it's doable but it will take some time to get all this digested and make sure it doesn't break any currently expected behavior. >--- dist_root:[000000]configure.com Sun Apr 11 20:45:43 2004 >+++ dist_root:[000000]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" Note that your patch is reversed. The normal procedure is to do $ diff oldfile newfile >-#ifdef __DECC >-#pragma message disable pragma >-#pragma member_alignment save >-#pragma nomember_alignment longword >-#pragma message save >-#pragma message disable misalgndmem >-#endif > struct itmlst_3 { > unsigned short int buflen; > unsigned short int itmcode; > void *bufadr; > unsigned short int *retlen; > }; >-#ifdef __DECC >-#pragma message restore >-#pragma member_alignment restore >-#endif Are these alignment shenanigans necessary? If so, it's hard to see how any of what's currently there works. >-#pragma nostandard >-#pragma extern_model save >-#pragma extern_model strict_refdef "LIB$INITIALIZ" nowrt >-#endif Shouldn't there be an "E" at the end of LIB$INITIALIZE? Thanks for all the hard work, John. I look forward to bringing Perl's CRTL compatibility into the 21st century. -- ________________________________________ Craig A. Berry mailto:[EMAIL PROTECTED] "... getting out of a sonnet is much more difficult than getting in." Brad Leithauser
