> 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:[000000.utils] c2ph.PL;1 76 10-FEB-2005 13:24:12.81 (RWED,RWED,RE,) Directory BUILD_ROOT:[000000.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
