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.
At 7:07 AM -0500 1/31/05, John E. Malmberg wrote: 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. 5.8.6 is current on all platforms. It has a couple of MakeMaker test failures on VMS that are unrelated to MakeMaker itself. Immediately upgrading to the latest version of PathTools (which includes File::Spec and Cwd) from CPAN would correct the root causes of those failures. 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). Also which baselevel has the changes that I submitted for handling UNIX file specifications based on the DECC$ feature logicals? 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. 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. -- Craig A. Berry mailto:[EMAIL PROTECTED] ... getting out of a sonnet is much more difficult than getting in. Brad Leithauser
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
Re: What is the stable version of Perl for VMS.
On Monday, January 31, 2005, at 08:39AM, John E. Malmberg [EMAIL PROTECTED]
wrote:
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.
They do, kinda. At least in the case of DECC$EFS_CASE_PRESERVE, we ignore it
and unversally downcase names like the old CRTL behavior, so everything based
on that assumption still works. If we try to honor case preservation, then we
have to modify everything that depends on case-leveled names.
After all, the DECC$ feature logicals will affect the
build now even with out the patches.
Some of them might. For case preservation, see above, but there are now lots
of feature logicals and I can guarantee I've never done tests with all of them
enabled.
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 your task should consist of locating the line in configure.com that says:
$ WC d_symlink='undef'
change it to
$ WC d_symlink=' + d_symlink + '
and work backwards from there to define the d_symlink DCL symbol when the
capability is truly present in the local CRTL. You'll need to create a small
test program, traditionally called try.c, build it, and see if it works. Look
for d_fcntl_can_lock as an example. (Incidentally, d_fcntl_can_lock should
be defined for the first time under VMS v8.2, but I have not attempted to
verify this.)
The change to configure.com may be all that's required.
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.
Anything in Perl that appropriately checks for $Config{d_symlink} will know
whether the capability is present.
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.
It may not be done consistently. Tests that check for $Config{d_symlink}
should require no modification. There may well be some, though, that skip on
VMS without checking this. You can find out pretty quickly what tests are
relevant by doing the following search from the top of the Perl source tree:
$ search [...]*.t symlink
Holler if you need further help.
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
Re: Minor ODS-5 build issue.
On Monday, January 31, 2005, at 03:00PM, John E. Malmberg [EMAIL PROTECTED] wrote: 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. Luckily I seldom clean up my directories as I apparently fixed this last November and never submitted it. See attached. configure_manicheck.patch Description: Binary data
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
Re: LARGEFILE configure issue
On Monday, January 31, 2005, at 04:40PM, John E. Malmberg [EMAIL PROTECTED] wrote: The configure tests for largefile support is based on if the integer type is native 64 bits. If you're looking at 5.8.6, all of the 64-bit tests were lumped together under 64-bit integers, which is just plain wrong. 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. 64-bit integers and long doubles do also work, but are currently still lumped together. In other words, I don't think we have provided for anyone who wants long doubles but not long ints. There is a separate part of Perl's 64-bitness called maximal 64-bit support enabled by -Duse64bitall and/or -Dusemorebits. It refers to very large memory support, and is not yet supported (yes, it's on my to-do list). Up through 5.8.6, we incorrectly reported that it was defined if any 64-bit option was chosen even though there was no attempt made to enable large memory support in the CRTL. 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) The appropriate checking is now done. See http://public.activestate.com/cgi-bin/perlbrowse?patch=23748 and http://public.activestate.com/cgi-bin/perlbrowse?patch=23775 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. 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. Perl has it's own Off_t that translates to either off_t or off64_t depending on configuration choices, and it does all seem to be working correctly now. If you configure bleadperl using -Duselargefiles and have any trouble getting it to work, do post here. 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.
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
