| 1 | Last Revised 02-June-1998 by Dan Sugalski <sugalskd@ous.edu> |
| 2 | Originally by Charles Bailey <bailey@newman.upenn.edu> |
| 3 | |
| 4 | * Important safety tip |
| 5 | |
| 6 | The build and install procedures have changed significantly from the 5.004 |
| 7 | releases! Make sure you read the "Building Perl" and "Installing Perl" |
| 8 | sections before you build or install. |
| 9 | |
| 10 | * Intro |
| 11 | |
| 12 | The VMS port of Perl is as functionally complete as any other Perl port |
| 13 | (and as complete as the ports on some Unix systems). The Perl binaries |
| 14 | provide all the Perl system calls that are either available under VMS or |
| 15 | reasonably emulated. There are some incompatibilites in process handling |
| 16 | (e.g the fork/exec model for creating subprocesses doesn't do what you |
| 17 | might expect under Unix), mainly because VMS and Unix handle processes and |
| 18 | sub-processes very differently. |
| 19 | |
| 20 | There are still some unimplemented system functions, and of coursse we |
| 21 | could use modules implementing useful VMS system services, so if you'd like |
| 22 | to lend a hand we'd love to have you. Join the Perl Porting Team Now! |
| 23 | |
| 24 | The current sources and build procedures have been tested on a VAX using |
| 25 | VaxC and Dec C, and on an AXP using Dec C. If you run into problems with |
| 26 | other compilers, please let us know. |
| 27 | |
| 28 | There are issues with varions versions of Dec C, so if you're not running a |
| 29 | relatively modern version, check the Dec C issues section later on in this |
| 30 | document. |
| 31 | |
| 32 | * Other required software |
| 33 | |
| 34 | In addition to VMS, you'll need: |
| 35 | 1) A C compiler. Dec C for AXP, or VAX C, Dec C, or gcc for the |
| 36 | VAX. |
| 37 | 2) A make tool. Dec's MMS (v2.6 or later), or MadGoat's free MMS |
| 38 | analog MMK (available from ftp.madgoat.com/madgoat) both work |
| 39 | just fine. Gnu Make might work, but it's been so long since |
| 40 | anyone's tested it that we're not sure. MMK's free, though, so |
| 41 | go ahead and use that. |
| 42 | |
| 43 | |
| 44 | If you want to include socket support, you'll need a TCP stack and either |
| 45 | Dec C, or socket libraries. See the Socket Support topic for more details. |
| 46 | |
| 47 | * Building Perl |
| 48 | |
| 49 | Building perl has two steps, configuration and compilation. |
| 50 | |
| 51 | To configure perl (a necessary first step), issue the command |
| 52 | |
| 53 | @CONFIGURE |
| 54 | |
| 55 | from the top of an unpacked perl directory. You'll be asked a series of |
| 56 | questions, and the answers to them (along with the capabilities of your C |
| 57 | compiler and network stack) will determine how perl's built. |
| 58 | |
| 59 | If you've got multiple C compilers installed, you'll have your choice of |
| 60 | which one to use. Using Dec C is recommended over Vax C--the compiler is |
| 61 | newer, and supported. (Vax C was decommisioned around 1993) Various older |
| 62 | versions had some gotchas, so if you're using a version older than 5.2, |
| 63 | check the Dec C Issues section. |
| 64 | |
| 65 | We'll also point out that Dec C will get you at least a ten-fold increase |
| 66 | in line-oriented IO over Vax C. The optimizer is amazingly better, too. If |
| 67 | you can use Dec C, then you *really*, *really* should. |
| 68 | |
| 69 | The configuration script will print out, at the very end, the MMS or MMK |
| 70 | command you need to compile perl. Issue it (exactly as printed) to start |
| 71 | the build. |
| 72 | |
| 73 | Once you issue your MMS command, sit back and wait. Perl should build and |
| 74 | link without a problem. If it doesn't, check the Gotchas to watch out for |
| 75 | section. If that doesn't help, send some mail to the VMSPERL mailing list. |
| 76 | Instructions are in the Mailing Lists section. |
| 77 | |
| 78 | As a handy shortcut, the command: |
| 79 | |
| 80 | @CONFIGURE "-des" |
| 81 | |
| 82 | (note the quotes and case) will choose reasonable defaults. (It takes Dec C |
| 83 | over Vax C, Dec C sockets over SOCKETSHR sockets, and either over no sockets) |
| 84 | |
| 85 | * Testing Perl |
| 86 | |
| 87 | Once Perl has built cleanly, you need to test it to make sure things work. |
| 88 | This step is very important--there are always things that can go wrong |
| 89 | somehow and get you a dysfunctional Perl. |
| 90 | |
| 91 | Testing is very easy, though, as there's a full test suite in the perl |
| 92 | distribution. To run the tests, enter the *exact* MMS line you used to |
| 93 | compile Perl and add the word "test" to the end, like this: |
| 94 | |
| 95 | Compile Command: |
| 96 | |
| 97 | $MMS/Macro=("__AXP__=1","decc=1","DECCRTL_SOCKETS=1") |
| 98 | |
| 99 | Test Command: |
| 100 | |
| 101 | $MMS/Macro=("__AXP__=1","decc=1","DECCRTL_SOCKETS=1") test |
| 102 | |
| 103 | MMS will run all the tests. This may take some time, as there are a lot of |
| 104 | tests. If any tests fail, there will be a note made on-screen. At the end |
| 105 | of all the tests, a summary of the tests, the number passed and failed, and |
| 106 | the time taken will be displayed. |
| 107 | |
| 108 | If any tests fail, it means something's wrong with Perl. If the test suite |
| 109 | hangs (some tests can take upwards of two or three minutes, or more if |
| 110 | you're on an especially slow machine, depending on you machine speed, so |
| 111 | don't be hasty), then the test *after* the last one displayed failed. Don't |
| 112 | install Perl unless you're confident that you're OK. Regardless of how |
| 113 | confident you are, make a bug report to the VMSPerl mailing list. |
| 114 | |
| 115 | If one or more tests fail, you can get more info on the failure by issuing |
| 116 | this command sequence: |
| 117 | |
| 118 | $ @[.VMS]TEST .typ "-v" [.subdir]test.T |
| 119 | |
| 120 | where ".typ" is the file type of the Perl images you just built (if you |
| 121 | didn't do anything special, use .EXE), and "[.subdir]test.T" is the test |
| 122 | that failed. For example, with a normal Perl build, if the test indicated |
| 123 | that [.op]time failed, then you'd do this: |
| 124 | |
| 125 | $ @[.VMS]TEST .EXE "-v" [.OP]TIME.T |
| 126 | |
| 127 | When you send in a bug report for failed tests, please include the output |
| 128 | from this command, which is run from the main source directory: |
| 129 | |
| 130 | MCR []MINIPERL "-V" |
| 131 | |
| 132 | Note that "-V" really is a capital V in double quotes. This will dump out a |
| 133 | couple of screens worth of config info, and can help us diagnose the problem. |
| 134 | |
| 135 | * Cleaning up and starting fresh |
| 136 | |
| 137 | If you need to recompile from scratch, you have to make sure you clean up |
| 138 | first. There's a procedure to do it--enter the *exact* MMS line you used to |
| 139 | compile and add "realclean" at the end, like this: |
| 140 | |
| 141 | Compile Command: |
| 142 | |
| 143 | $MMS/Macro=("__AXP__=1","decc=1","DECCRTL_SOCKETS=1") |
| 144 | |
| 145 | Cleanup Command: |
| 146 | |
| 147 | $MMS/Macro=("__AXP__=1","decc=1","DECCRTL_SOCKETS=1") realclean |
| 148 | |
| 149 | If you don't do this, things may behave erratically. They might not, too, |
| 150 | so it's best to be sure and do it. |
| 151 | |
| 152 | * Installing Perl |
| 153 | |
| 154 | There are several steps you need to take to get Perl installed and |
| 155 | running. |
| 156 | |
| 157 | 1) Create a directory somewhere and define the concealed logical PERL_ROOT |
| 158 | to point to it. For example, DEFINE/TRANS=(CONC,TERM) PERL_ROOT dka200:[perl.] |
| 159 | |
| 160 | 2) Run the install script via: |
| 161 | |
| 162 | MMS install |
| 163 | |
| 164 | or |
| 165 | |
| 166 | MMK install |
| 167 | |
| 168 | If for some reason it complains about target INSTALL being up to date, |
| 169 | throw a /FORCE switch on the MMS or MMK command. |
| 170 | |
| 171 | 3) Either define the symbol PERL somewhere, such as |
| 172 | SYS$MANAGER:SYLOGIN.COM, to be "PERL :== $PERL_ROOT:[000000]PERL.EXE", or |
| 173 | install Perl into DCLTABLES.EXE (Check out the section "Installing Perl |
| 174 | into DCLTABLES" for more info), or put the image in a directory that's in |
| 175 | your DCL$PATH (if you're using VMS 6.2 or higher). |
| 176 | |
| 177 | 4) Optionally define the command PERLDOC as |
| 178 | PERLDOC :== $PERL_ROOT:[000000]PERL PERL_ROOT:[LIB.POD]PERLDOC.COM -T |
| 179 | Note that if you wish to use most as a pager please see |
| 180 | ftp://space.mit.edu/pub/davis/ for both most and slang. |
| 181 | |
| 182 | 5) Optionally define the command PERLBUG (the Perl bug report generator) as |
| 183 | PERLBUG :== $PERL_ROOT:[000000]PERL PERL_ROOT:[LIB]PERLBUG.COM" |
| 184 | |
| 185 | 6) Optionally define the command POD2MAN (Converts POD files to nroff |
| 186 | source suitable for converting to man pages. Also quiets complaints during |
| 187 | module builds) as |
| 188 | |
| 189 | DEFINE/NOLOG POD2MAN PERL_ROOT:[LIB.POD]POD2MAN.COM |
| 190 | POD2MAN :== $PERL_ROOT:[000000]PERL POD2MAN |
| 191 | |
| 192 | * Installing Perl into DCLTABLES |
| 193 | |
| 194 | Courtesy of Brad Hughes: |
| 195 | |
| 196 | Put the following, modified to reflect where your .exe is, in PERL.CLD: |
| 197 | |
| 198 | define verb perl |
| 199 | image perl_root:[exe]perl.exe |
| 200 | cliflags (foreign) |
| 201 | |
| 202 | and then |
| 203 | |
| 204 | $ set command perl /table=sys$common:[syslib]dcltables.exe - |
| 205 | /output=sys$common:[syslib]dcltables.exe |
| 206 | $ install replace sys$common:[syslib]dcltables.exe |
| 207 | |
| 208 | and you don't need perl :== $perl_root:[exe]perl.exe. |
| 209 | |
| 210 | * Changing compile-time things |
| 211 | |
| 212 | Most of the user-definable features of Perl are enabled or disabled in |
| 213 | [.VMS]CONFIG.VMS. There's code in there to Do The Right Thing, but that may |
| 214 | end up being the wrong thing for you. Make sure you understand what you're |
| 215 | doing, since changes here can get you a busted perl. |
| 216 | |
| 217 | Odds are that there's nothing here to change, unless you're on a version of |
| 218 | VMS later than 6.2 and Dec C later than 5.6. Even if you are, the correct |
| 219 | values will still be chosen, most likely. Poking around here should be |
| 220 | unnecessary. |
| 221 | |
| 222 | The one exception is the various *DIR install locations. Changing those |
| 223 | requires changes in genconfig.pl as well. Be really careful if you need to |
| 224 | change these,a s they can cause some fairly subtle problems. |
| 225 | |
| 226 | * Extra things in the Perl distribution |
| 227 | |
| 228 | In addition to the standard stuff that gets installed, there are two |
| 229 | optional extensions, DCLSYM and STDIO, that are handy. Instructions for |
| 230 | these two modules are in [.VMS.EXT.DCLSYM] and [.VMS.EXT.STDIO], |
| 231 | respectively. |
| 232 | |
| 233 | * Socket Support |
| 234 | |
| 235 | Perl includes a number of functions for IP sockets, which are available if |
| 236 | you choose to compile Perl with socket support. (See the section Compiling |
| 237 | Perl for more info on selecting a socket stack) Since IP networking is an |
| 238 | optional addition to VMS, there are several different IP stacks |
| 239 | available. How well integrated they are into the system depends on the |
| 240 | stack, your version of VMS, and the version of your C compiler. |
| 241 | |
| 242 | The most portable solution uses the SOCKETSHR library. In combination with |
| 243 | either UCX or NetLib, this supports all the major TCP stacks (Multinet, |
| 244 | Pathways, TCPWare, UCX, and CMU) on all versions of VMS Perl runs on, with |
| 245 | all the compilers on both VAX and Alpha. The socket interface is also |
| 246 | consistent across versions of VMS and C compilers. It has a problem with |
| 247 | UDP sockets when used with Multinet, though, so you should be aware of |
| 248 | that. |
| 249 | |
| 250 | The other solution available is to use the socket routines built into Dec |
| 251 | C. Which routines are available depend on the version of VMS you're |
| 252 | running, and require proper UCX emulation by your TCP/IP vendor. |
| 253 | Relatively current versions of Multinet, TCPWare, Pathway, and UCX all |
| 254 | provide the required libraries--check your manuals or release notes to see |
| 255 | if your version is new enough. |
| 256 | |
| 257 | * Reporting Bugs |
| 258 | |
| 259 | If you come across what you think might be a bug in Perl, please report |
| 260 | it. There's a script in PERL_ROOT:[UTILS], perlbug, that walks you through |
| 261 | the process of creating a bug report. This script includes details of your |
| 262 | installation, and is very handy. Completed bug reports should go to |
| 263 | PERLBUG@PERL.COM. |
| 264 | |
| 265 | * Gotchas to watch out for |
| 266 | |
| 267 | Probably the single biggest gotcha in compiling Perl is giving the wrong |
| 268 | switches to MMS/MMK when you build. Use *exactly* what the configure script |
| 269 | prints! |
| 270 | |
| 271 | The next big gotcha is directory depth. Perl can create directories four |
| 272 | and five levels deep during the build, so you don't have to be too deep to |
| 273 | start to hit the RMS 8 level point. It's best to do a |
| 274 | $DEFINE/TRANS=(CONC,TERM) PERLSRC disk:[dir.dir.dir.perldir.]" (note the |
| 275 | trailing period) and $SET DEFAULT PERLSRC:[000000] before building. Perl |
| 276 | modules can be just as bad (or worse), so watch out for them, too. The |
| 277 | configuration script will warn if it thinks you're too deep. |
| 278 | |
| 279 | Finally, the third thing that bites people is leftover pieces from a failed |
| 280 | build. If things go wrong, make sure you do a "(MMK|MMS|make) realclean" |
| 281 | before you rebuild. |
| 282 | |
| 283 | * Dec C issues |
| 284 | |
| 285 | Note to DECC users: Some early versions (pre-5.2, some pre-4. If you're Dec |
| 286 | C 5.x or higher, with current patches if anym you're fine) of the DECCRTL |
| 287 | contained a few bugs which affect Perl performance: |
| 288 | - Newlines are lost on I/O through pipes, causing lines to run together. |
| 289 | This shows up as RMS RTB errors when reading from a pipe. You can |
| 290 | work around this by having one process write data to a file, and |
| 291 | then having the other read the file, instead of the pipe. This is |
| 292 | fixed in version 4 of DECC. |
| 293 | - The modf() routine returns a non-integral value for some values above |
| 294 | INT_MAX; the Perl "int" operator will return a non-integral value in |
| 295 | these cases. This is fixed in version 4 of DECC. |
| 296 | - On the AXP, if SYSNAM privilege is enabled, the CRTL chdir() routine |
| 297 | changes the process default device and directory permanently, even |
| 298 | though the call specified that the change should not persist after |
| 299 | Perl exited. This is fixed by DEC CSC patch AXPACRT04_061. |
| 300 | |
| 301 | * Mailing Lists |
| 302 | |
| 303 | There are several mailing lists available to the Perl porter. For VMS |
| 304 | specific issues (including both Perl questions and installation problems) |
| 305 | there is the VMSPERL mailing list. It's usually a low-volume (10-12 |
| 306 | messages a week) mailing list. |
| 307 | |
| 308 | The subscription address is VMSPERL-REQUEST@NEWMAN.UPENN.EDU. Send a mail |
| 309 | message with just the words SUBSCRIBE VMSPERL in the body of the message. |
| 310 | |
| 311 | The VMSPERL mailing list address is VMSPERL@NEWMAN.UPENN.EDU. Any mail |
| 312 | sent there gets echoed to all subscribers of the list. |
| 313 | |
| 314 | The Perl5-Porters list is for anyone involved in porting Perl to a |
| 315 | platform. This includes you, if you want to participate. It's a high-volume |
| 316 | list (60-100 messages a day during active development times), so be sure |
| 317 | you want to be there. The subscription address is |
| 318 | Perl5-Porters-request@perl.org. Send a message with just the word SUBSCRIBE |
| 319 | in the body. The posting address is Perl5-Porters@perl.org. |
| 320 | |
| 321 | * Acknowledgements |
| 322 | |
| 323 | A real big thanks needs to go to Charles Bailey |
| 324 | <bailey@newman.upenn.edu>, who is ultimately responsible for Perl 5.004 |
| 325 | running on VMS. Without him, nothing the rest of us have done would be at |
| 326 | all important. |
| 327 | |
| 328 | There are, of course, far too many people involved in the porting and testing |
| 329 | of Perl to mention everyone who deserves it, so please forgive us if we've |
| 330 | missed someone. That said, special thanks are due to the following: |
| 331 | Tim Adye <T.J.Adye@rl.ac.uk> |
| 332 | for the VMS emulations of getpw*() |
| 333 | David Denholm <denholm@conmat.phys.soton.ac.uk> |
| 334 | for extensive testing and provision of pipe and SocketShr code, |
| 335 | Mark Pizzolato <mark@infocomm.com> |
| 336 | for the getredirection() code |
| 337 | Rich Salz <rsalz@bbn.com> |
| 338 | for readdir() and related routines |
| 339 | Peter Prymmer <pvhp@lns62.lns.cornell.edu) |
| 340 | for extensive testing, as well as development work on |
| 341 | configuration and documentation for VMS Perl, |
| 342 | Dan Sugalski <sugalsd@stargate.lbcc.cc.or.us> |
| 343 | for extensive contributions to recent version support, |
| 344 | development of VMS-specific extensions, and dissemination |
| 345 | of information about VMS Perl, |
| 346 | the Stanford Synchrotron Radiation Laboratory and the |
| 347 | Laboratory of Nuclear Studies at Cornell University for |
| 348 | the the opportunity to test and develop for the AXP, |
| 349 | and to the entire VMSperl group for useful advice and suggestions. In |
| 350 | addition the perl5-porters deserve credit for their creativity and |
| 351 | willingness to work with the VMS newcomers. Finally, the greatest debt of |
| 352 | gratitude is due to Larry Wall <larry@wall.org>, for having the ideas which |
| 353 | have made our sleepless nights possible. |
| 354 | |
| 355 | Thanks, |
| 356 | The VMSperl group |