| 1 | =head1 NAME |
| 2 | |
| 3 | Install - Build and Installation guide for perl5. |
| 4 | |
| 5 | =head1 SYNOPSIS |
| 6 | |
| 7 | The basic steps to build and install perl5 on a Unix system are: |
| 8 | |
| 9 | rm -f config.sh |
| 10 | sh Configure |
| 11 | make |
| 12 | make test |
| 13 | make install |
| 14 | |
| 15 | # You may also wish to add these: |
| 16 | (cd /usr/include && h2ph *.h sys/*.h) |
| 17 | (cd pod && make html && mv *.html <www home dir>) |
| 18 | (cd pod && make tex && <process the latex files>) |
| 19 | |
| 20 | Each of these is explained in further detail below. |
| 21 | |
| 22 | For information on non-Unix systems, see the section on |
| 23 | L<"Porting Information"> below. |
| 24 | |
| 25 | =head1 DESCRIPTION |
| 26 | |
| 27 | You should probably at least skim through this entire document before |
| 28 | proceeding. Special notes specific to this release are identified |
| 29 | by B<NOTE>. |
| 30 | |
| 31 | This document is written in pod format as an easy way to indicate its |
| 32 | structure. The pod format is described in pod/perlpod.pod, but you can |
| 33 | read it as is with any pager or editor. |
| 34 | |
| 35 | If you're building Perl on a non-Unix system, you should also read |
| 36 | the README file specific to your operating system, since this may |
| 37 | provide additional or different instructions for building Perl. |
| 38 | |
| 39 | =head1 Space Requirements |
| 40 | |
| 41 | The complete perl5 source tree takes up about 7 MB of disk space. |
| 42 | The complete tree after completing C<make> takes roughly |
| 43 | 15 MB, though the actual total is likely to be quite |
| 44 | system-dependent. The installation directories need something |
| 45 | on the order of 7 MB, though again that value is system-dependent. |
| 46 | |
| 47 | =head1 Start with a Fresh Distribution |
| 48 | |
| 49 | If you have built perl before, you should clean out the build directory |
| 50 | with the command |
| 51 | |
| 52 | make realclean |
| 53 | |
| 54 | The results of a Configure run are stored in the config.sh file. If |
| 55 | you are upgrading from a previous version of perl, or if you change |
| 56 | systems or compilers or make other significant changes, or if you are |
| 57 | experiencing difficulties building perl, you should probably I<not> |
| 58 | re-use your old config.sh. Simply remove it or rename it, e.g. |
| 59 | |
| 60 | mv config.sh config.sh.old |
| 61 | |
| 62 | If you wish to use your old config.sh, be especially attentive to the |
| 63 | version and architecture-specific questions and answers. For example, |
| 64 | the default directory for architecture-dependent library modules |
| 65 | includes the version name. By default, Configure will reuse your old |
| 66 | name (e.g. /opt/perl/lib/i86pc-solaris/5.003) even if you're running |
| 67 | Configure for a different version, e.g. 5.004. Yes, Configure should |
| 68 | probably check and correct for this, but it doesn't, presently. |
| 69 | Similarly, if you used a shared libperl.so (see below) with version |
| 70 | numbers, you will probably want to adjust them as well. |
| 71 | |
| 72 | Also, be careful to check your architecture name. Some Linux systems |
| 73 | call themselves i486, while others use i586. If you pick up a |
| 74 | precompiled binary, it might not use the same name. |
| 75 | |
| 76 | In short, if you wish to use your old config.sh, I recommend running |
| 77 | Configure interactively rather than blindly accepting the defaults. |
| 78 | |
| 79 | =head1 Run Configure |
| 80 | |
| 81 | Configure will figure out various things about your system. Some |
| 82 | things Configure will figure out for itself, other things it will ask |
| 83 | you about. To accept the default, just press C<RETURN>. The default |
| 84 | is almost always ok. |
| 85 | |
| 86 | After it runs, Configure will perform variable substitution on all the |
| 87 | F<*.SH> files and offer to run B<make depend>. |
| 88 | |
| 89 | Configure supports a number of useful options. Run B<Configure -h> |
| 90 | to get a listing. To compile with gcc, for example, you can run |
| 91 | |
| 92 | sh Configure -Dcc=gcc |
| 93 | |
| 94 | This is the preferred way to specify gcc (or another alternative |
| 95 | compiler) so that the hints files can set appropriate defaults. |
| 96 | |
| 97 | If you want to use your old config.sh but override some of the items |
| 98 | with command line options, you need to use B<Configure -O>. |
| 99 | |
| 100 | If you are willing to accept all the defaults, and you want terse |
| 101 | output, you can run |
| 102 | |
| 103 | sh Configure -des |
| 104 | |
| 105 | By default, for most systems, perl will be installed in |
| 106 | /usr/local/{bin, lib, man}. You can specify a different 'prefix' for |
| 107 | the default installation directory, when Configure prompts you or by |
| 108 | using the Configure command line option -Dprefix='/some/directory', |
| 109 | e.g. |
| 110 | |
| 111 | sh Configure -Dprefix=/opt/perl |
| 112 | |
| 113 | If your prefix contains the string "perl", then the directories |
| 114 | are simplified. For example, if you use prefix=/opt/perl, |
| 115 | then Configure will suggest /opt/perl/lib instead of |
| 116 | /opt/perl/lib/perl5/. |
| 117 | |
| 118 | By default, Configure will compile perl to use dynamic loading if |
| 119 | your system supports it. If you want to force perl to be compiled |
| 120 | statically, you can either choose this when Configure prompts you or |
| 121 | you can use the Configure command line option -Uusedl. |
| 122 | |
| 123 | =head2 GNU-style configure |
| 124 | |
| 125 | If you prefer the GNU-style B<configure> command line interface, you can |
| 126 | use the supplied B<configure> command, e.g. |
| 127 | |
| 128 | CC=gcc ./configure |
| 129 | |
| 130 | The B<configure> script emulates a few of the more common configure |
| 131 | options. Try |
| 132 | |
| 133 | ./configure --help |
| 134 | |
| 135 | for a listing. |
| 136 | |
| 137 | Cross compiling is not supported. |
| 138 | |
| 139 | For systems that do not distinguish the files "Configure" and |
| 140 | "configure", Perl includes a copy of B<configure> named |
| 141 | B<configure.gnu>. |
| 142 | |
| 143 | =head2 Extensions |
| 144 | |
| 145 | By default, Configure will offer to build every extension which appears |
| 146 | to be supported. For example, Configure will offer to build GDBM_File |
| 147 | only if it is able to find the gdbm library. (See examples below.) |
| 148 | DynaLoader, Fcntl, and IO are always built by default. Configure does |
| 149 | not contain code to test for POSIX compliance, so POSIX is always built |
| 150 | by default as well. If you wish to skip POSIX, you can set the |
| 151 | Configure variable useposix=false either in a hint file or from the |
| 152 | Configure command line. Similarly, the Opcode extension is always built |
| 153 | by default, but you can skip it by setting the Configure variable |
| 154 | useopcode=false either in a hint file for from the command line. |
| 155 | |
| 156 | Even if you do not have dynamic loading, you must still build the |
| 157 | DynaLoader extension; you should just build the stub dl_none.xs |
| 158 | version. (Configure will suggest this as the default.) |
| 159 | |
| 160 | In summary, here are the Configure command-line variables you can set |
| 161 | to turn off each extension: |
| 162 | |
| 163 | DB_File i_db |
| 164 | DynaLoader (Must always be included as a static extension) |
| 165 | Fcntl (Always included by default) |
| 166 | GDBM_File i_gdbm |
| 167 | IO (Always included by default) |
| 168 | NDBM_File i_ndbm |
| 169 | ODBM_File i_dbm |
| 170 | POSIX useposix |
| 171 | SDBM_File (Always included by default) |
| 172 | Opcode useopcode |
| 173 | Socket d_socket |
| 174 | |
| 175 | Thus to skip the NDBM_File extension, you can use |
| 176 | |
| 177 | sh Configure -Ui_ndbm |
| 178 | |
| 179 | Again, this is taken care of automatically if you don't have the ndbm |
| 180 | library. |
| 181 | |
| 182 | Of course, you may always run Configure interactively and select only |
| 183 | the extensions you want. |
| 184 | |
| 185 | Finally, if you have dynamic loading (most modern Unix systems do) |
| 186 | remember that these extensions do not increase the size of your perl |
| 187 | executable, nor do they impact start-up time, so you probably might as |
| 188 | well build all the ones that will work on your system. |
| 189 | |
| 190 | =head2 Including locally-installed libraries |
| 191 | |
| 192 | Perl5 comes with interfaces to number of database extensions, including |
| 193 | dbm, ndbm, gdbm, and Berkeley db. For each extension, if |
| 194 | Configure can find the appropriate header files and libraries, it will |
| 195 | automatically include that extension. The gdbm and db libraries |
| 196 | are B<not> included with perl. See the library documentation for |
| 197 | how to obtain the libraries. |
| 198 | |
| 199 | I<Note:> If your database header (.h) files are not in a |
| 200 | directory normally searched by your C compiler, then you will need to |
| 201 | include the appropriate B<-I/your/directory> option when prompted by |
| 202 | Configure. If your database library (.a) files are not in a directory |
| 203 | normally searched by your C compiler and linker, then you will need to |
| 204 | include the appropriate B<-L/your/directory> option when prompted by |
| 205 | Configure. See the examples below. |
| 206 | |
| 207 | =head2 Examples |
| 208 | |
| 209 | =over 4 |
| 210 | |
| 211 | =item gdbm in /usr/local |
| 212 | |
| 213 | Suppose you have gdbm and want Configure to find it and build the |
| 214 | GDBM_File extension. This examples assumes you have F<gdbm.h> |
| 215 | installed in F</usr/local/include/gdbm.h> and F<libgdbm.a> installed in |
| 216 | F</usr/local/lib/libgdbm.a>. Configure should figure all the |
| 217 | necessary steps out automatically. |
| 218 | |
| 219 | Specifically, when Configure prompts you for flags for |
| 220 | your C compiler, you should include C<-I/usr/local/include>. |
| 221 | |
| 222 | When Configure prompts you for linker flags, you should include |
| 223 | C<-L/usr/local/lib>. |
| 224 | |
| 225 | If you are using dynamic loading, then when Configure prompts you for |
| 226 | linker flags for dynamic loading, you should again include |
| 227 | C<-L/usr/local/lib>. |
| 228 | |
| 229 | Again, this should all happen automatically. If you want to accept the |
| 230 | defaults for all the questions and have Configure print out only terse |
| 231 | messages, then you can just run |
| 232 | |
| 233 | sh Configure -des |
| 234 | |
| 235 | and Configure should include the GDBM_File extension automatically. |
| 236 | |
| 237 | This should actually work if you have gdbm installed in any of |
| 238 | (/usr/local, /opt/local, /usr/gnu, /opt/gnu, /usr/GNU, or /opt/GNU). |
| 239 | |
| 240 | =item gdbm in /usr/you |
| 241 | |
| 242 | Suppose you have gdbm installed in some place other than /usr/local/, |
| 243 | but you still want Configure to find it. To be specific, assume you |
| 244 | have F</usr/you/include/gdbm.h> and F</usr/you/lib/libgdbm.a>. You |
| 245 | still have to add B<-I/usr/you/include> to cc flags, but you have to take |
| 246 | an extra step to help Configure find F<libgdbm.a>. Specifically, when |
| 247 | Configure prompts you for library directories, you have to add |
| 248 | F</usr/you/lib> to the list. |
| 249 | |
| 250 | It is possible to specify this from the command line too (all on one |
| 251 | line): |
| 252 | |
| 253 | sh Configure -des \ |
| 254 | -Dlocincpth="/usr/you/include" \ |
| 255 | -Dloclibpth="/usr/you/lib" |
| 256 | |
| 257 | C<locincpth> is a space-separated list of include directories to search. |
| 258 | Configure will automatically add the appropriate B<-I> directives. |
| 259 | |
| 260 | C<loclibpth> is a space-separated list of library directories to search. |
| 261 | Configure will automatically add the appropriate B<-L> directives. If |
| 262 | you have some libraries under F</usr/local/> and others under |
| 263 | F</usr/you>, then you have to include both, namely |
| 264 | |
| 265 | sh Configure -des \ |
| 266 | -Dlocincpth="/usr/you/include /usr/local/include" \ |
| 267 | -Dloclibpth="/usr/you/lib /usr/local/lib" |
| 268 | |
| 269 | =back |
| 270 | |
| 271 | =head2 Installation Directories |
| 272 | |
| 273 | The installation directories can all be changed by answering the |
| 274 | appropriate questions in Configure. For convenience, all the |
| 275 | installation questions are near the beginning of Configure. |
| 276 | |
| 277 | By default, Configure uses the following directories for |
| 278 | library files (archname is a string like sun4-sunos, determined |
| 279 | by Configure) |
| 280 | |
| 281 | /usr/local/lib/perl5/archname/5.004 |
| 282 | /usr/local/lib/perl5/ |
| 283 | /usr/local/lib/perl5/site_perl/archname |
| 284 | /usr/local/lib/perl5/site_perl |
| 285 | |
| 286 | and the following directories for manual pages: |
| 287 | |
| 288 | /usr/local/man/man1 |
| 289 | /usr/local/lib/perl5/man/man3 |
| 290 | |
| 291 | (Actually, Configure recognizes the SVR3-style |
| 292 | /usr/local/man/l_man/man1 directories, if present, and uses those |
| 293 | instead.) The module man pages are stuck in that strange spot so that |
| 294 | they don't collide with other man pages stored in /usr/local/man/man3, |
| 295 | and so that Perl's man pages don't hide system man pages. On some |
| 296 | systems, B<man less> would end up calling up Perl's less.pm module man |
| 297 | page, rather than the B<less> program. |
| 298 | |
| 299 | If you specify a prefix that contains the string "perl", then the |
| 300 | directory structure is simplified. For example, if you Configure with |
| 301 | -Dprefix=/opt/perl, then the defaults are |
| 302 | |
| 303 | /opt/perl/lib/archname/5.004 |
| 304 | /opt/perl/lib |
| 305 | /opt/perl/lib/site_perl/archname |
| 306 | /opt/perl/lib/site_perl |
| 307 | |
| 308 | /opt/perl/man/man1 |
| 309 | /opt/perl/man/man3 |
| 310 | |
| 311 | The perl executable will search the libraries in the order given |
| 312 | above. |
| 313 | |
| 314 | The directories site_perl and site_perl/archname are empty, but are |
| 315 | intended to be used for installing local or site-wide extensions. Perl |
| 316 | will automatically look in these directories. Previously, most sites |
| 317 | just put their local extensions in with the standard distribution. |
| 318 | |
| 319 | In order to support using things like #!/usr/local/bin/perl5.004 after |
| 320 | a later version is released, architecture-dependent libraries are |
| 321 | stored in a version-specific directory, such as |
| 322 | /usr/local/lib/perl5/archname/5.004/. In Perl 5.000 and 5.001, these |
| 323 | files were just stored in /usr/local/lib/perl5/archname/. If you will |
| 324 | not be using 5.001 binaries, you can delete the standard extensions from |
| 325 | the /usr/local/lib/perl5/archname/ directory. Locally-added extensions |
| 326 | can be moved to the site_perl and site_perl/archname directories. |
| 327 | |
| 328 | Again, these are just the defaults, and can be changed as you run |
| 329 | Configure. |
| 330 | |
| 331 | =head2 Changing the installation directory |
| 332 | |
| 333 | Configure distinguishes between the directory in which perl (and its |
| 334 | associated files) should be installed and the directory in which it |
| 335 | will eventually reside. For most sites, these two are the same; for |
| 336 | sites that use AFS, this distinction is handled automatically. |
| 337 | However, sites that use software such as B<depot> to manage software |
| 338 | packages may also wish to install perl into a different directory and |
| 339 | use that management software to move perl to its final destination. |
| 340 | This section describes how to do this. Someday, Configure may support |
| 341 | an option -Dinstallprefix=/foo to simplify this. |
| 342 | |
| 343 | Suppose you want to install perl under the F</tmp/perl5> directory. |
| 344 | You can edit F<config.sh> and change all the install* variables to |
| 345 | point to F</tmp/perl5> instead of F</usr/local/wherever>. You could |
| 346 | also set them all from the Configure command line. Or, you can |
| 347 | automate this process by placing the following lines in a file |
| 348 | F<config.over> B<before> you run Configure (replace /tmp/perl5 by a |
| 349 | directory of your choice): |
| 350 | |
| 351 | installprefix=/tmp/perl5 |
| 352 | test -d $installprefix || mkdir $installprefix |
| 353 | test -d $installprefix/bin || mkdir $installprefix/bin |
| 354 | installarchlib=`echo $installarchlib | sed "s!$prefix!$installprefix!"` |
| 355 | installbin=`echo $installbin | sed "s!$prefix!$installprefix!"` |
| 356 | installman1dir=`echo $installman1dir | sed "s!$prefix!$installprefix!"` |
| 357 | installman3dir=`echo $installman3dir | sed "s!$prefix!$installprefix!"` |
| 358 | installprivlib=`echo $installprivlib | sed "s!$prefix!$installprefix!"` |
| 359 | installscript=`echo $installscript | sed "s!$prefix!$installprefix!"` |
| 360 | installsitelib=`echo $installsitelib | sed "s!$prefix!$installprefix!"` |
| 361 | installsitearch=`echo $installsitearch | sed "s!$prefix!$installprefix!"` |
| 362 | |
| 363 | Then, you can Configure and install in the usual way: |
| 364 | |
| 365 | sh Configure -des |
| 366 | make |
| 367 | make test |
| 368 | make install |
| 369 | |
| 370 | =head2 Creating an installable tar archive |
| 371 | |
| 372 | If you need to install perl on many identical systems, it is |
| 373 | convenient to compile it once and create an archive that can be |
| 374 | installed on multiple systems. Here's one way to do that: |
| 375 | |
| 376 | # Set up config.over to install perl into a different directory, |
| 377 | # e.g. /tmp/perl5 (see previous part). |
| 378 | sh Configure -des |
| 379 | make |
| 380 | make test |
| 381 | make install |
| 382 | cd /tmp/perl5 |
| 383 | tar cvf ../perl5-archive.tar . |
| 384 | # Then, on each machine where you want to install perl, |
| 385 | cd /usr/local # Or wherever you specified as $prefix |
| 386 | tar xvf perl5-archive.tar |
| 387 | |
| 388 | =head2 Configure-time Options |
| 389 | |
| 390 | There are several different ways to Configure and build perl for your |
| 391 | system. For most users, the defaults are sensible and will work. |
| 392 | Some users, however, may wish to further customize perl. Here are |
| 393 | some of the main things you can change. |
| 394 | |
| 395 | =head2 Binary Compatibility With Earlier Versions of Perl 5 |
| 396 | |
| 397 | If you have dynamically loaded extensions that you built under |
| 398 | perl 5.003 and that you wish to continue to use with perl 5.004, then you |
| 399 | need to ensure that 5.004 remains binary compatible with 5.003. |
| 400 | |
| 401 | Starting with Perl 5.003, all functions in the Perl C source code have |
| 402 | been protected by default by the prefix Perl_ (or perl_) so that you |
| 403 | may link with third-party libraries without fear of namespace |
| 404 | collisions. This change broke compatibility with version 5.002, so |
| 405 | installing 5.003 or 5.004 over 5.002 or earlier will force you to |
| 406 | re-build and install all of your dynamically loadable extensions. |
| 407 | (The standard extensions supplied with Perl are handled |
| 408 | automatically). You can turn off this namespace protection by adding |
| 409 | -DNO_EMBED to your ccflags variable in config.sh. |
| 410 | |
| 411 | Perl 5.003's namespace protection was incomplete, but this has |
| 412 | been fixed in 5.004. However, some sites may need to maintain |
| 413 | complete binary compatibility with Perl 5.003. If you are building |
| 414 | Perl for such a site, then when B<Configure> asks if you want binary |
| 415 | compatibility, answer "y". |
| 416 | |
| 417 | On the other hand, if you are embedding perl into another application |
| 418 | and want the maximum namespace protection, then you probably ought to |
| 419 | answer "n" when B<Configure> asks if you want binary compatibility. |
| 420 | |
| 421 | The default answer of "y" to maintain binary compatibility is probably |
| 422 | appropriate for almost everyone. |
| 423 | |
| 424 | =head2 Selecting File IO mechanisms |
| 425 | |
| 426 | Previous versions of perl used the standard IO mechanisms as defined in |
| 427 | <stdio.h>. Versions 5.003_02 and later of perl allow alternate IO |
| 428 | mechanisms via a "PerlIO" abstraction, but the stdio mechanism is still |
| 429 | the default and is the only supported mechanism. |
| 430 | |
| 431 | This PerlIO abstraction can be enabled either on the Configure command |
| 432 | line with |
| 433 | |
| 434 | sh Configure -Duseperlio |
| 435 | |
| 436 | or interactively at the appropriate Configure prompt. |
| 437 | |
| 438 | If you choose to use the PerlIO abstraction layer, there are two |
| 439 | (experimental) possibilities for the underlying IO calls. These have been |
| 440 | tested to some extent on some platforms, but are not guaranteed to work |
| 441 | everywhere. |
| 442 | |
| 443 | =over 4 |
| 444 | |
| 445 | =item 1. |
| 446 | |
| 447 | AT&T's "sfio". This has superior performance to <stdio.h> in many |
| 448 | cases, and is extensible by the use of "discipline" modules. Sfio |
| 449 | currently only builds on a subset of the UNIX platforms perl supports. |
| 450 | Because the data structures are completely different from stdio, perl |
| 451 | extension modules or external libraries may not work. This |
| 452 | configuration exists to allow these issues to be worked on. |
| 453 | |
| 454 | This option requires the 'sfio' package to have been built and installed. |
| 455 | A (fairly old) version of sfio is in CPAN, and work is in progress to make |
| 456 | it more easily buildable by adding Configure support. |
| 457 | |
| 458 | You select this option by |
| 459 | |
| 460 | sh Configure -Duseperlio -Dusesfio |
| 461 | |
| 462 | If you have already selected -Duseperlio, and if Configure detects |
| 463 | that you have sfio, then sfio will be the default suggested by |
| 464 | Configure. |
| 465 | |
| 466 | I<Note:> On some systems, sfio's B<iffe> configuration script fails |
| 467 | to detect that you have an C<atexit> function (or equivalent). |
| 468 | Apparently, this is a problem at least for some versions of Linux |
| 469 | and SunOS 4. |
| 470 | |
| 471 | You can test if you have this problem by trying the following shell |
| 472 | script. (You may have to add some extra cflags and libraries. A |
| 473 | portable version of this may eventually make its way into Configure.) |
| 474 | |
| 475 | #!/bin/sh |
| 476 | cat > try.c <<'EOCP' |
| 477 | #include <stdio.h> |
| 478 | main() { printf("42\n"); } |
| 479 | EOCP |
| 480 | cc -o try try.c -lsfio |
| 481 | val=`./try` |
| 482 | if test X$val = X42; then |
| 483 | echo "Your sfio looks ok" |
| 484 | else |
| 485 | echo "Your sfio has the exit problem." |
| 486 | fi |
| 487 | |
| 488 | If you have this problem, the fix is to go back to your sfio sources |
| 489 | and correct iffe's guess about atexit (or whatever is appropriate for |
| 490 | your platform.) |
| 491 | |
| 492 | There also might be a more recent release of Sfio that fixes your |
| 493 | problem. |
| 494 | |
| 495 | =item 2. |
| 496 | |
| 497 | Normal stdio IO, but with all IO going through calls to the PerlIO |
| 498 | abstraction layer. This configuration can be used to check that perl and |
| 499 | extension modules have been correctly converted to use the PerlIO |
| 500 | abstraction. |
| 501 | |
| 502 | This configuration should work on all platforms (but might not). |
| 503 | |
| 504 | You select this option via: |
| 505 | |
| 506 | sh Configure -Duseperlio -Uusesfio |
| 507 | |
| 508 | If you have already selected -Duseperlio, and if Configure does not |
| 509 | detect sfio, then this will be the default suggested by Configure. |
| 510 | |
| 511 | =back |
| 512 | |
| 513 | =head2 Building a shared libperl.so Perl library |
| 514 | |
| 515 | Currently, for most systems, the main perl executable is built by |
| 516 | linking the "perl library" libperl.a with perlmain.o, your static |
| 517 | extensions (usually just DynaLoader.a) and various extra libraries, |
| 518 | such as -lm. |
| 519 | |
| 520 | On some systems that support dynamic loading, it may be possible to |
| 521 | replace libperl.a with a shared libperl.so. If you anticipate building |
| 522 | several different perl binaries (e.g. by embedding libperl into |
| 523 | different programs, or by using the optional compiler extension), then |
| 524 | you might wish to build a shared libperl.so so that all your binaries |
| 525 | can share the same library. |
| 526 | |
| 527 | The disadvantages are that there may be a significant performance |
| 528 | penalty associated with the shared libperl.so, and that the overall |
| 529 | mechanism is still rather fragile with respect to different versions |
| 530 | and upgrades. |
| 531 | |
| 532 | In terms of performance, on my test system (Solaris 2.5_x86) the perl |
| 533 | test suite took roughly 15% longer to run with the shared libperl.so. |
| 534 | Your system and typical applications may well give quite different |
| 535 | results. |
| 536 | |
| 537 | The default name for the shared library is typically something like |
| 538 | libperl.so.3.2 (for Perl 5.003_02) or libperl.so.302 or simply |
| 539 | libperl.so. Configure tries to guess a sensible naming convention |
| 540 | based on your C library name. Since the library gets installed in a |
| 541 | version-specific architecture-dependent directory, the exact name |
| 542 | isn't very important anyway, as long as your linker is happy. |
| 543 | |
| 544 | For some systems (mostly SVR4), building a shared libperl is required |
| 545 | for dynamic loading to work, and hence is already the default. |
| 546 | |
| 547 | You can elect to build a shared libperl by |
| 548 | |
| 549 | sh Configure -Duseshrplib |
| 550 | |
| 551 | To actually build perl, you must add the current working directory to your |
| 552 | LD_LIBRARY_PATH environment variable before running make. You can do |
| 553 | this with |
| 554 | |
| 555 | LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH |
| 556 | |
| 557 | for Bourne-style shells, or |
| 558 | |
| 559 | setenv LD_LIBRARY_PATH `pwd` |
| 560 | |
| 561 | for Csh-style shells. You *MUST* do this before running make. |
| 562 | Folks running NeXT OPENSTEP must substitute DYLD_LIBRARY_PATH for |
| 563 | LD_LIBRARY_PATH above. |
| 564 | |
| 565 | There is also an potential problem with the shared perl library if you |
| 566 | want to have more than one "flavor" of the same version of perl (e.g. |
| 567 | with and without -DDEBUGGING). For example, suppose you build and |
| 568 | install a standard Perl 5.004 with a shared library. Then, suppose you |
| 569 | try to build Perl 5.004 with -DDEBUGGING enabled, but everything else |
| 570 | the same, including all the installation directories. How can you |
| 571 | ensure that your newly built perl will link with your newly built |
| 572 | libperl.so.4 rather with the installed libperl.so.4? The answer is |
| 573 | that you might not be able to. The installation directory is encoded |
| 574 | in the perl binary with the LD_RUN_PATH environment variable (or |
| 575 | equivalent ld command-line option). On Solaris, you can override that |
| 576 | with LD_LIBRARY_PATH; on Linux you can't. |
| 577 | |
| 578 | The only reliable answer is that you should specify a different |
| 579 | directory for the architecture-dependent library for your -DDEBUGGING |
| 580 | version of perl. You can do this with by changing all the *archlib* |
| 581 | variables in config.sh, namely archlib, archlib_exp, and |
| 582 | installarchlib, to point to your new architecture-dependent library. |
| 583 | |
| 584 | =head2 Malloc Issues |
| 585 | |
| 586 | Perl relies heavily on malloc(3) to grow data structures as needed, so |
| 587 | perl's performance can be noticeably affected by the performance of |
| 588 | the malloc function on your system. |
| 589 | |
| 590 | The perl source is shipped with a version of malloc that is very fast |
| 591 | but somewhat wasteful of space. On the other hand, your system's |
| 592 | malloc() function is probably a bit slower but also a bit more frugal. |
| 593 | |
| 594 | For many uses, speed is probably the most important consideration, so |
| 595 | the default behavior (for most systems) is to use the malloc supplied |
| 596 | with perl. However, if you will be running very large applications |
| 597 | (e.g. Tk or PDL) or if your system already has an excellent malloc, or |
| 598 | if you are experiencing difficulties with extensions that use |
| 599 | third-party libraries that call malloc, then you might wish to use |
| 600 | your system's malloc. (Or, you might wish to explore the experimental |
| 601 | malloc flags discussed below.) |
| 602 | |
| 603 | To build without perl's malloc, you can use the Configure command |
| 604 | |
| 605 | sh Configure -Uusemymalloc |
| 606 | |
| 607 | or you can answer 'n' at the appropriate interactive Configure prompt. |
| 608 | |
| 609 | =head2 Malloc Performance Flags |
| 610 | |
| 611 | If you are using Perl's malloc, you may add one or |
| 612 | more of the following items to your C<cflags> config.sh variable |
| 613 | to change its behavior in potentially useful ways. You can find out |
| 614 | more about these flags by reading the F<malloc.c> source. |
| 615 | In a future version of perl, these might be enabled by default. |
| 616 | |
| 617 | =over 4 |
| 618 | |
| 619 | =item -DEMERGENCY_SBRK |
| 620 | |
| 621 | If this macro is defined, running out of memory need not be a fatal |
| 622 | error: a memory pool can allocated by assigning to the special |
| 623 | variable C<$^M>. |
| 624 | |
| 625 | =item -DPACK_MALLOC |
| 626 | |
| 627 | If C<PACK_MALLOC> is defined, malloc.c uses a slightly different |
| 628 | algorithm for small allocations (up to 64 bytes long). Such small |
| 629 | allocations are quite common in typical Perl scripts. |
| 630 | |
| 631 | The expected memory savings (with 8-byte alignment in C<alignbytes>) is |
| 632 | about 20% for typical Perl usage. The expected slowdown due to the |
| 633 | additional malloc overhead is in fractions of a percent. (It is hard |
| 634 | to measure because of the effect of the saved memory on speed). |
| 635 | |
| 636 | =item -DTWO_POT_OPTIMIZE |
| 637 | |
| 638 | If C<TWO_POT_OPTIMIZE> is defined, malloc.c uses a slightly different |
| 639 | algorithm for large allocations that are close to a power of two |
| 640 | (starting with 16K). Such allocations are typical for big hashes and |
| 641 | special-purpose scripts, especially image processing. If you will be |
| 642 | manipulating very large blocks with sizes close to powers of two, it |
| 643 | might be wise to define this macro. |
| 644 | |
| 645 | The expected saving of memory is 0-100% (100% in applications which |
| 646 | require most memory in such 2**n chunks). The expected slowdown is |
| 647 | negligible. |
| 648 | |
| 649 | =back |
| 650 | |
| 651 | =head2 Other Compiler Flags |
| 652 | |
| 653 | For most users, all of the Configure defaults are fine. However, |
| 654 | you can change a number of factors in the way perl is built |
| 655 | by adding appropriate B<-D> directives to your ccflags variable in |
| 656 | config.sh. |
| 657 | |
| 658 | For example, you can replace the rand() and srand() functions in the |
| 659 | perl source by any other random number generator by a trick such as the |
| 660 | following: |
| 661 | |
| 662 | sh Configure -Dccflags='-Drand=random -Dsrand=srandom' |
| 663 | |
| 664 | or by adding C<-Drand=random> and C<-Dsrandom=srandom> to your ccflags |
| 665 | at the appropriate Configure prompt. (You may also have to adjust |
| 666 | Configure's guess for 'randbits' as well.) |
| 667 | |
| 668 | =head2 What if it doesn't work? |
| 669 | |
| 670 | =over 4 |
| 671 | |
| 672 | =item Running Configure Interactively |
| 673 | |
| 674 | If Configure runs into trouble, remember that you can always run |
| 675 | Configure interactively so that you can check (and correct) its |
| 676 | guesses. |
| 677 | |
| 678 | All the installation questions have been moved to the top, so you don't |
| 679 | have to wait for them. Once you've handled them (and your C compiler and |
| 680 | flags) you can type C<&-d> at the next Configure prompt and Configure |
| 681 | will use the defaults from then on. |
| 682 | |
| 683 | If you find yourself trying obscure command line incantations and |
| 684 | config.over tricks, I recommend you run Configure interactively |
| 685 | instead. You'll probably save yourself time in the long run. |
| 686 | |
| 687 | =item Hint files |
| 688 | |
| 689 | The perl distribution includes a number of system-specific hints files |
| 690 | in the hints/ directory. If one of them matches your system, Configure |
| 691 | will offer to use that hint file. |
| 692 | |
| 693 | Several of the hint files contain additional important information. |
| 694 | If you have any problems, it is a good idea to read the relevant hint |
| 695 | file for further information. See F<hints/solaris_2.sh> for an |
| 696 | extensive example. |
| 697 | |
| 698 | =item *** WHOA THERE!!! *** |
| 699 | |
| 700 | Occasionally, Configure makes a wrong guess. For example, on SunOS |
| 701 | 4.1.3, Configure incorrectly concludes that tzname[] is in the |
| 702 | standard C library. The hint file is set up to correct for this. You |
| 703 | will see a message: |
| 704 | |
| 705 | *** WHOA THERE!!! *** |
| 706 | The recommended value for $d_tzname on this machine was "undef"! |
| 707 | Keep the recommended value? [y] |
| 708 | |
| 709 | You should always keep the recommended value unless, after reading the |
| 710 | relevant section of the hint file, you are sure you want to try |
| 711 | overriding it. |
| 712 | |
| 713 | If you are re-using an old config.sh, the word "previous" will be |
| 714 | used instead of "recommended". Again, you will almost always want |
| 715 | to keep the previous value, unless you have changed something on your |
| 716 | system. |
| 717 | |
| 718 | For example, suppose you have added libgdbm.a to your system |
| 719 | and you decide to reconfigure perl to use GDBM_File. When you run |
| 720 | Configure again, you will need to add -lgdbm to the list of libraries. |
| 721 | Now, Configure will find your gdbm library and will issue a message: |
| 722 | |
| 723 | *** WHOA THERE!!! *** |
| 724 | The previous value for $i_gdbm on this machine was "undef"! |
| 725 | Keep the previous value? [y] |
| 726 | |
| 727 | In this case, you do I<not> want to keep the previous value, so you |
| 728 | should answer 'n'. (You'll also have to manually add GDBM_File to |
| 729 | the list of dynamic extensions to build.) |
| 730 | |
| 731 | =item Changing Compilers |
| 732 | |
| 733 | If you change compilers or make other significant changes, you should |
| 734 | probably I<not> re-use your old config.sh. Simply remove it or |
| 735 | rename it, e.g. mv config.sh config.sh.old. Then rerun Configure |
| 736 | with the options you want to use. |
| 737 | |
| 738 | This is a common source of problems. If you change from B<cc> to |
| 739 | B<gcc>, you should almost always remove your old config.sh. |
| 740 | |
| 741 | =item Propagating your changes to config.sh |
| 742 | |
| 743 | If you make any changes to F<config.sh>, you should propagate |
| 744 | them to all the .SH files by running B<sh Configure -S>. You will |
| 745 | then have to rebuild by running |
| 746 | |
| 747 | make depend |
| 748 | make |
| 749 | |
| 750 | =item config.over |
| 751 | |
| 752 | You can also supply a shell script config.over to over-ride Configure's |
| 753 | guesses. It will get loaded up at the very end, just before config.sh |
| 754 | is created. You have to be careful with this, however, as Configure |
| 755 | does no checking that your changes make sense. See the section on |
| 756 | L<"Changing the installation directory"> for an example. |
| 757 | |
| 758 | =item config.h |
| 759 | |
| 760 | Many of the system dependencies are contained in F<config.h>. |
| 761 | F<Configure> builds F<config.h> by running the F<config_h.SH> script. |
| 762 | The values for the variables are taken from F<config.sh>. |
| 763 | |
| 764 | If there are any problems, you can edit F<config.h> directly. Beware, |
| 765 | though, that the next time you run B<Configure>, your changes will be |
| 766 | lost. |
| 767 | |
| 768 | =item cflags |
| 769 | |
| 770 | If you have any additional changes to make to the C compiler command |
| 771 | line, they can be made in F<cflags.SH>. For instance, to turn off the |
| 772 | optimizer on F<toke.c>, find the line in the switch structure for |
| 773 | F<toke.c> and put the command C<optimize='-g'> before the C<;;>. You |
| 774 | can also edit F<cflags> directly, but beware that your changes will be |
| 775 | lost the next time you run B<Configure>. |
| 776 | |
| 777 | To change the C flags for all the files, edit F<config.sh> |
| 778 | and change either C<$ccflags> or C<$optimize>, |
| 779 | and then re-run B<sh Configure -S ; make depend>. |
| 780 | |
| 781 | =item No sh |
| 782 | |
| 783 | If you don't have sh, you'll have to copy the sample file config_H to |
| 784 | config.h and edit the config.h to reflect your system's peculiarities. |
| 785 | You'll probably also have to extensively modify the extension building |
| 786 | mechanism. |
| 787 | |
| 788 | =item Porting information |
| 789 | |
| 790 | Specific information for the OS/2, Plan9, VMS and Win32 ports are in the |
| 791 | corresponding subdirectories. Additional information, including |
| 792 | a glossary of all those config.sh variables, is in the Porting |
| 793 | subdirectory. |
| 794 | |
| 795 | Ports for other systems may also be available. You should check out |
| 796 | L<"http://www.perl.com/CPAN/ports"> for current information on ports to |
| 797 | various other operating systems. |
| 798 | |
| 799 | =back |
| 800 | |
| 801 | =head1 make depend |
| 802 | |
| 803 | This will look for all the includes. |
| 804 | The output is stored in F<makefile>. The only difference between |
| 805 | F<Makefile> and F<makefile> is the dependencies at the bottom of |
| 806 | F<makefile>. If you have to make any changes, you should edit |
| 807 | F<makefile>, not F<Makefile> since the Unix B<make> command reads |
| 808 | F<makefile> first. (On non-Unix systems, the output may be stored in |
| 809 | a different file. Check the value of $firstmakefile in your config.sh |
| 810 | if in doubt.) |
| 811 | |
| 812 | Configure will offer to do this step for you, so it isn't listed |
| 813 | explicitly above. |
| 814 | |
| 815 | =head1 make |
| 816 | |
| 817 | This will attempt to make perl in the current directory. |
| 818 | |
| 819 | If you can't compile successfully, try some of the following ideas. |
| 820 | If none of them help, and careful reading of the error message and |
| 821 | the relevant manual pages on your system doesn't help, you can |
| 822 | send a message to either the comp.lang.perl.misc newsgroup or to |
| 823 | perlbug@perl.com with an accurate description of your problem. |
| 824 | See L<"Reporting Problems"> below. |
| 825 | |
| 826 | =over 4 |
| 827 | |
| 828 | =item * |
| 829 | |
| 830 | If you used a hint file, try reading the comments in the hint file |
| 831 | for further tips and information. |
| 832 | |
| 833 | =item * |
| 834 | |
| 835 | If you can successfully build F<miniperl>, but the process crashes |
| 836 | during the building of extensions, you should run |
| 837 | |
| 838 | make minitest |
| 839 | |
| 840 | to test your version of miniperl. |
| 841 | |
| 842 | =item locale |
| 843 | |
| 844 | If you have any locale-related environment variables set, try |
| 845 | unsetting them. I have some reports that some versions of IRIX hang |
| 846 | while running B<./miniperl configpm> with locales other than the C |
| 847 | locale. See the discussion under L<make test> below about locales. |
| 848 | |
| 849 | =item * |
| 850 | |
| 851 | If you get duplicates upon linking for malloc et al, add -DHIDEMYMALLOC |
| 852 | or -DEMBEDMYMALLOC to your ccflags variable in config.sh. |
| 853 | |
| 854 | =item varargs |
| 855 | |
| 856 | If you get varargs problems with gcc, be sure that gcc is installed |
| 857 | correctly. When using gcc, you should probably have i_stdarg='define' |
| 858 | and i_varargs='undef' in config.sh. The problem is usually solved by |
| 859 | running fixincludes correctly. If you do change config.sh, don't |
| 860 | forget to propagate your changes (see |
| 861 | L<"Propagating your changes to config.sh"> below). |
| 862 | See also the L<"vsprintf"> item below. |
| 863 | |
| 864 | =item * |
| 865 | |
| 866 | If you get error messages such as the following (the exact line |
| 867 | numbers will vary in different versions of perl): |
| 868 | |
| 869 | util.c: In function `Perl_croak': |
| 870 | util.c:962: number of arguments doesn't match prototype |
| 871 | proto.h:45: prototype declaration |
| 872 | |
| 873 | it might well be a symptom of the gcc "varargs problem". See the |
| 874 | previous L<"varargs"> item. |
| 875 | |
| 876 | =item Solaris and SunOS dynamic loading |
| 877 | |
| 878 | If you have problems with dynamic loading using gcc on SunOS or |
| 879 | Solaris, and you are using GNU as and GNU ld, you may need to add |
| 880 | B<-B/bin/> (for SunOS) or B<-B/usr/ccs/bin/> (for Solaris) to your |
| 881 | $ccflags, $ldflags, and $lddlflags so that the system's versions of as |
| 882 | and ld are used. Alternatively, you can use the GCC_EXEC_PREFIX |
| 883 | environment variable to ensure that Sun's as and ld are used. Consult |
| 884 | your gcc documentation for further information on the B<-B> option and |
| 885 | the GCC_EXEC_PREFIX variable. |
| 886 | |
| 887 | =item ld.so.1: ./perl: fatal: relocation error: |
| 888 | |
| 889 | If you get this message on SunOS or Solaris, and you're using gcc, |
| 890 | it's probably the GNU as or GNU ld problem in the previous item |
| 891 | L<"Solaris and SunOS dynamic loading">. |
| 892 | |
| 893 | =item * |
| 894 | |
| 895 | If you run into dynamic loading problems, check your setting of |
| 896 | the LD_LIBRARY_PATH environment variable. If you're creating a static |
| 897 | Perl library (libperl.a rather than libperl.so) it should build |
| 898 | fine with LD_LIBRARY_PATH unset, though that may depend on details |
| 899 | of your local set-up. |
| 900 | |
| 901 | =item dlopen: stub interception failed |
| 902 | |
| 903 | The primary cause of the 'dlopen: stub interception failed' message is |
| 904 | that the LD_LIBRARY_PATH environment variable includes a directory |
| 905 | which is a symlink to /usr/lib (such as /lib). |
| 906 | |
| 907 | The reason this causes a problem is quite subtle. The file libdl.so.1.0 |
| 908 | actually *only* contains functions which generate 'stub interception |
| 909 | failed' errors! The runtime linker intercepts links to |
| 910 | "/usr/lib/libdl.so.1.0" and links in internal implementation of those |
| 911 | functions instead. [Thanks to Tim Bunce for this explanation.] |
| 912 | |
| 913 | =item nm extraction |
| 914 | |
| 915 | If Configure seems to be having trouble finding library functions, |
| 916 | try not using nm extraction. You can do this from the command line |
| 917 | with |
| 918 | |
| 919 | sh Configure -Uusenm |
| 920 | |
| 921 | or by answering the nm extraction question interactively. |
| 922 | If you have previously run Configure, you should I<not> reuse your old |
| 923 | config.sh. |
| 924 | |
| 925 | =item vsprintf |
| 926 | |
| 927 | If you run into problems with vsprintf in compiling util.c, the |
| 928 | problem is probably that Configure failed to detect your system's |
| 929 | version of vsprintf(). Check whether your system has vprintf(). |
| 930 | (Virtually all modern Unix systems do.) Then, check the variable |
| 931 | d_vprintf in config.sh. If your system has vprintf, it should be: |
| 932 | |
| 933 | d_vprintf='define' |
| 934 | |
| 935 | If Configure guessed wrong, it is likely that Configure guessed wrong |
| 936 | on a number of other common functions too. You are probably better off |
| 937 | re-running Configure without using nm extraction (see previous item). |
| 938 | |
| 939 | =item Optimizer |
| 940 | |
| 941 | If you can't compile successfully, try turning off your compiler's |
| 942 | optimizer. Edit config.sh and change the line |
| 943 | |
| 944 | optimize='-O' |
| 945 | |
| 946 | to something like |
| 947 | |
| 948 | optimize=' ' |
| 949 | |
| 950 | then propagate your changes with B<sh Configure -S> and rebuild |
| 951 | with B<make depend; make>. |
| 952 | |
| 953 | =item * |
| 954 | |
| 955 | If you still can't compile successfully, try adding a C<-DCRIPPLED_CC> |
| 956 | flag. (Just because you get no errors doesn't mean it compiled right!) |
| 957 | This simplifies some complicated expressions for compilers that get |
| 958 | indigestion easily. |
| 959 | |
| 960 | =item Missing functions |
| 961 | |
| 962 | If you have missing routines, you probably need to add some library or |
| 963 | other, or you need to undefine some feature that Configure thought was |
| 964 | there but is defective or incomplete. Look through config.h for |
| 965 | likely suspects. |
| 966 | |
| 967 | =item * |
| 968 | |
| 969 | Some compilers will not compile or optimize the larger files without |
| 970 | some extra switches to use larger jump offsets or allocate larger |
| 971 | internal tables. You can customize the switches for each file in |
| 972 | F<cflags>. It's okay to insert rules for specific files into |
| 973 | F<makefile> since a default rule only takes effect in the absence of a |
| 974 | specific rule. |
| 975 | |
| 976 | =item Missing dbmclose |
| 977 | |
| 978 | SCO prior to 3.2.4 may be missing dbmclose(). An upgrade to 3.2.4 |
| 979 | that includes libdbm.nfs (which includes dbmclose()) may be available. |
| 980 | |
| 981 | =item Warning (will try anyway): No library found for -lposix |
| 982 | |
| 983 | If you see such a message during the building of an extension, but |
| 984 | the extension passes its tests anyway (see L<"make test"> below), |
| 985 | then don't worry about the warning message. The extension |
| 986 | Makefile.PL goes looking for various libraries needed on various |
| 987 | systems; few systems will need all the possible libraries listed. |
| 988 | For example, a system may have -lcposix or -lposix, but it's |
| 989 | unlikely to have both, so most users will see warnings for the one |
| 990 | they don't have. The message 'will try anyway' is intended to |
| 991 | reassure you that the process is continuing. |
| 992 | |
| 993 | On the other hand, if you are building GDBM_File and you get the |
| 994 | message |
| 995 | |
| 996 | Warning (will try anyway): No library found for -lgdbm |
| 997 | |
| 998 | then it's likely you're going to run into trouble somewhere along |
| 999 | the line, since it's hard to see how you can use the GDBM_File |
| 1000 | extension without the -lgdbm library. |
| 1001 | |
| 1002 | It is true that, in principle, Configure could have figured all of |
| 1003 | this out, but Configure and the extension building process are not |
| 1004 | quite that tightly coordinated. |
| 1005 | |
| 1006 | =item sh: ar: not found |
| 1007 | |
| 1008 | This is a message from your shell telling you that the command 'ar' |
| 1009 | was not found. You need to check your PATH environment variable to |
| 1010 | make sure that it includes the directory with the 'ar' command. This |
| 1011 | is a common problem on Solaris, where 'ar' is in the F</usr/ccs/bin> |
| 1012 | directory. |
| 1013 | |
| 1014 | =item db-recno failure on tests 51, 53 and 55 |
| 1015 | |
| 1016 | Old versions of the DB library (including the DB library which comes |
| 1017 | with FreeBSD 2.1) had broken handling of recno databases with modified |
| 1018 | bval settings. Upgrade your DB library or OS. |
| 1019 | |
| 1020 | =item * |
| 1021 | |
| 1022 | Some additional things that have been reported for either perl4 or perl5: |
| 1023 | |
| 1024 | Genix may need to use libc rather than libc_s, or #undef VARARGS. |
| 1025 | |
| 1026 | NCR Tower 32 (OS 2.01.01) may need -W2,-Sl,2000 and #undef MKDIR. |
| 1027 | |
| 1028 | UTS may need one or more of -DCRIPPLED_CC, B<-K> or B<-g>, and undef LSTAT. |
| 1029 | |
| 1030 | If you get syntax errors on '(', try -DCRIPPLED_CC. |
| 1031 | |
| 1032 | Machines with half-implemented dbm routines will need to #undef I_ODBM |
| 1033 | |
| 1034 | =back |
| 1035 | |
| 1036 | =head1 make test |
| 1037 | |
| 1038 | This will run the regression tests on the perl you just made. If it |
| 1039 | doesn't say "All tests successful" then something went wrong. See the |
| 1040 | file F<t/README> in the F<t> subdirectory. Note that you can't run the |
| 1041 | tests in background if this disables opening of /dev/tty. |
| 1042 | |
| 1043 | If B<make test> bombs out, just B<cd> to the F<t> directory and run |
| 1044 | F<./TEST> by hand to see if it makes any difference. If individual tests |
| 1045 | bomb, you can run them by hand, e.g., |
| 1046 | |
| 1047 | ./perl op/groups.t |
| 1048 | |
| 1049 | Another way to get more detailed information about failed tests and |
| 1050 | individual subtests is to B<cd> to the F<t> directory and run |
| 1051 | |
| 1052 | ./perl harness |
| 1053 | |
| 1054 | (this assumes that I<most> tests succeed, since F<harness> uses |
| 1055 | complicated constructs). |
| 1056 | |
| 1057 | You can also read the individual tests to see if there are any helpful |
| 1058 | comments that apply to your system. |
| 1059 | |
| 1060 | B<Note>: One possible reason for errors is that some external programs |
| 1061 | may be broken due to the combination of your environment and the way |
| 1062 | C<make test> exercises them. For example, this may happen if you have |
| 1063 | one or more of these environment variables set: C<LC_ALL LC_CTYPE |
| 1064 | LC_COLLATE LANG>. In some versions of UNIX, the non-English locales |
| 1065 | are known to cause programs to exhibit mysterious errors. |
| 1066 | |
| 1067 | If you have any of the above environment variables set, please try |
| 1068 | |
| 1069 | setenv LC_ALL C |
| 1070 | |
| 1071 | (for C shell) or |
| 1072 | |
| 1073 | LC_ALL=C;export LC_ALL |
| 1074 | |
| 1075 | for Bourne or Korn shell) from the command line and then retry C<make |
| 1076 | test>. If the tests then succeed, you may have a broken program that |
| 1077 | is confusing the testing. Please run the troublesome test by hand as |
| 1078 | shown above and see whether you can locate the program. Look for |
| 1079 | things like: C<exec, `backquoted command`, system, open("|...")> or |
| 1080 | C<open("...|")>. All these mean that Perl is trying to run some |
| 1081 | external program. |
| 1082 | |
| 1083 | =head1 make install |
| 1084 | |
| 1085 | This will put perl into the public directory you specified to |
| 1086 | B<Configure>; by default this is F</usr/local/bin>. It will also try |
| 1087 | to put the man pages in a reasonable place. It will not nroff the man |
| 1088 | pages, however. You may need to be root to run B<make install>. If you |
| 1089 | are not root, you must own the directories in question and you should |
| 1090 | ignore any messages about chown not working. |
| 1091 | |
| 1092 | If you want to see exactly what will happen without installing |
| 1093 | anything, you can run |
| 1094 | |
| 1095 | ./perl installperl -n |
| 1096 | ./perl installman -n |
| 1097 | |
| 1098 | B<make install> will install the following: |
| 1099 | |
| 1100 | perl, |
| 1101 | perl5.nnn where nnn is the current release number. This |
| 1102 | will be a link to perl. |
| 1103 | suidperl, |
| 1104 | sperl5.nnn If you requested setuid emulation. |
| 1105 | a2p awk-to-perl translator |
| 1106 | cppstdin This is used by perl -P, if your cc -E can't |
| 1107 | read from stdin. |
| 1108 | c2ph, pstruct Scripts for handling C structures in header files. |
| 1109 | s2p sed-to-perl translator |
| 1110 | find2perl find-to-perl translator |
| 1111 | h2ph Extract constants and simple macros from C headers |
| 1112 | h2xs Converts C .h header files to Perl extensions. |
| 1113 | perlbug Tool to report bugs in Perl. |
| 1114 | perldoc Tool to read perl's pod documentation. |
| 1115 | pl2pm Convert Perl 4 .pl files to Perl 5 .pm modules |
| 1116 | pod2html, Converters from perl's pod documentation format |
| 1117 | pod2latex, to other useful formats. |
| 1118 | pod2man, and |
| 1119 | pod2text |
| 1120 | splain Describe Perl warnings and errors |
| 1121 | |
| 1122 | library files in $privlib and $archlib specified to |
| 1123 | Configure, usually under /usr/local/lib/perl5/. |
| 1124 | man pages in the location specified to Configure, usually |
| 1125 | something like /usr/local/man/man1. |
| 1126 | module in the location specified to Configure, usually |
| 1127 | man pages under /usr/local/lib/perl5/man/man3. |
| 1128 | pod/*.pod in $privlib/pod/. |
| 1129 | |
| 1130 | Installperl will also create the library directories $siteperl and |
| 1131 | $sitearch listed in config.sh. Usually, these are something like |
| 1132 | /usr/local/lib/perl5/site_perl/ |
| 1133 | /usr/local/lib/perl5/site_perl/$archname |
| 1134 | where $archname is something like sun4-sunos. These directories |
| 1135 | will be used for installing extensions. |
| 1136 | |
| 1137 | Perl's *.h header files and the libperl.a library are also installed |
| 1138 | under $archlib so that any user may later build new extensions, run the |
| 1139 | optional Perl compiler, or embed the perl interpreter into another |
| 1140 | program even if the Perl source is no longer available. |
| 1141 | |
| 1142 | =head1 Coexistence with earlier versions of perl5 |
| 1143 | |
| 1144 | You can safely install the current version of perl5 and still run scripts |
| 1145 | under the old binaries for versions 5.003 and later ONLY. Instead of |
| 1146 | starting your script with #!/usr/local/bin/perl, just start it with |
| 1147 | #!/usr/local/bin/perl5.003 (or whatever version you want to run.) |
| 1148 | If you want to retain a version of Perl 5 prior to 5.003, you'll |
| 1149 | need to install the current version in a separate directory tree, |
| 1150 | since some of the architecture-independent library files have changed |
| 1151 | in incompatible ways. |
| 1152 | |
| 1153 | The architecture-dependent files are stored in a version-specific |
| 1154 | directory (such as F</usr/local/lib/perl5/sun4-sunos/5.004>) so that |
| 1155 | they are still accessible. I<Note:> Perl 5.000 and 5.001 did not |
| 1156 | put their architecture-dependent libraries in a version-specific |
| 1157 | directory. They are simply in F</usr/local/lib/perl5/$archname>. If |
| 1158 | you will not be using 5.000 or 5.001, you may safely remove those |
| 1159 | files. |
| 1160 | |
| 1161 | The standard library files in F</usr/local/lib/perl5> |
| 1162 | should be usable by all versions of perl5. |
| 1163 | |
| 1164 | Most extensions will probably not need to be recompiled to use with a newer |
| 1165 | version of perl. If you do run into problems, and you want to continue |
| 1166 | to use the old version of perl along with your extension, simply move |
| 1167 | those extension files to the appropriate version directory, such as |
| 1168 | F</usr/local/lib/perl/archname/5.003>. Then Perl 5.003 will find your |
| 1169 | files in the 5.003 directory, and newer versions of perl will find your |
| 1170 | newer extension in the site_perl directory. |
| 1171 | |
| 1172 | Some users may prefer to keep all versions of perl in completely |
| 1173 | separate directories. One convenient way to do this is by |
| 1174 | using a separate prefix for each version, such as |
| 1175 | |
| 1176 | sh Configure -Dprefix=/opt/perl5.004 |
| 1177 | |
| 1178 | and adding /opt/perl5.004/bin to the shell PATH variable. Such users |
| 1179 | may also wish to add a symbolic link /usr/local/bin/perl so that |
| 1180 | scripts can still start with #!/usr/local/bin/perl. |
| 1181 | |
| 1182 | =head1 Coexistence with perl4 |
| 1183 | |
| 1184 | You can safely install perl5 even if you want to keep perl4 around. |
| 1185 | |
| 1186 | By default, the perl5 libraries go into F</usr/local/lib/perl5/>, so |
| 1187 | they don't override the perl4 libraries in F</usr/local/lib/perl/>. |
| 1188 | |
| 1189 | In your /usr/local/bin directory, you should have a binary named |
| 1190 | F<perl4.036>. That will not be touched by the perl5 installation |
| 1191 | process. Most perl4 scripts should run just fine under perl5. |
| 1192 | However, if you have any scripts that require perl4, you can replace |
| 1193 | the C<#!> line at the top of them by C<#!/usr/local/bin/perl4.036> |
| 1194 | (or whatever the appropriate pathname is). See pod/perltrap.pod |
| 1195 | for possible problems running perl4 scripts under perl5. |
| 1196 | |
| 1197 | =head1 cd /usr/include; h2ph *.h sys/*.h |
| 1198 | |
| 1199 | Some perl scripts need to be able to obtain information from |
| 1200 | the system header files. This command will convert the most commonly used |
| 1201 | header files in F</usr/include> into files that can be easily interpreted |
| 1202 | by perl. These files will be placed in the architectural library directory |
| 1203 | you specified to B<Configure>; by default this is |
| 1204 | F</usr/local/lib/perl5/ARCH/VERSION>, where B<ARCH> is your architecture |
| 1205 | (such as C<sun4-solaris>) and B<VERSION> is the version of perl you are |
| 1206 | building (for example, C<5.004>). |
| 1207 | |
| 1208 | B<Note:> Due to differences in the C and perl languages, the |
| 1209 | conversion of the header files is not perfect. You will probably have |
| 1210 | to hand-edit some of the converted files to get them to parse |
| 1211 | correctly. For example, h2ph breaks spectacularly on type casting and |
| 1212 | certain structures. |
| 1213 | |
| 1214 | =head1 cd pod && make html && mv *.html (www home dir) |
| 1215 | |
| 1216 | Some sites may wish to make the documentation in the pod/ directory |
| 1217 | available in HTML format. Type |
| 1218 | |
| 1219 | cd pod && make html && mv *.html <www home dir> |
| 1220 | |
| 1221 | where F<www home dir> is wherever your site keeps HTML files. |
| 1222 | |
| 1223 | =head1 cd pod && make tex && (process the latex files) |
| 1224 | |
| 1225 | Some sites may also wish to make the documentation in the pod/ directory |
| 1226 | available in TeX format. Type |
| 1227 | |
| 1228 | (cd pod && make tex && <process the latex files>) |
| 1229 | |
| 1230 | =head1 Reporting Problems |
| 1231 | |
| 1232 | If you have difficulty building perl, and none of the advice in this |
| 1233 | file helps, and careful reading of the error message and the relevant |
| 1234 | manual pages on your system doesn't help either, then you should send a |
| 1235 | message to either the comp.lang.perl.misc newsgroup or to |
| 1236 | perlbug@perl.com with an accurate description of your problem. |
| 1237 | |
| 1238 | Please include the I<output> of the B<./myconfig> shell script |
| 1239 | that comes with the distribution. Alternatively, you can use the |
| 1240 | B<perlbug> program that comes with the perl distribution, |
| 1241 | but you need to have perl compiled and installed before you can use it. |
| 1242 | |
| 1243 | You might also find helpful information in the F<Porting> |
| 1244 | directory of the perl distribution. |
| 1245 | |
| 1246 | =head1 DOCUMENTATION |
| 1247 | |
| 1248 | Read the manual entries before running perl. The main documentation is |
| 1249 | in the pod/ subdirectory and should have been installed during the |
| 1250 | build process. Type B<man perl> to get started. Alternatively, you |
| 1251 | can type B<perldoc perl> to use the supplied B<perldoc> script. This |
| 1252 | is sometimes useful for finding things in the library modules. |
| 1253 | |
| 1254 | Under UNIX, you can produce a documentation book in postscript form |
| 1255 | along with its I<Table of Contents> by going to the pod/ subdirectory |
| 1256 | and running (either): |
| 1257 | |
| 1258 | ./roffitall -groff # If you have GNU groff installed |
| 1259 | ./roffitall -psroff # If you have psroff |
| 1260 | |
| 1261 | This will leave you with two postscript files ready to be printed. |
| 1262 | (You may need to fix the roffitall command to use your local troff |
| 1263 | set-up.) |
| 1264 | |
| 1265 | Note that you must have performed the installation already before |
| 1266 | running the above, since the script collects the installed files to |
| 1267 | generate the documentation. |
| 1268 | |
| 1269 | =head1 AUTHOR |
| 1270 | |
| 1271 | Andy Dougherty <doughera@lafcol.lafayette.edu>, borrowing I<very> heavily |
| 1272 | from the original README by Larry Wall. |
| 1273 | |
| 1274 | =head1 LAST MODIFIED |
| 1275 | |
| 1276 | $Id: INSTALL,v 1.3 1997/02/28 16:34:11 doughera Released $ |