forked from schacon/perl
/
INSTALL
2591 lines (1954 loc) · 101 KB
/
INSTALL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
=head1 NAME
Install - Build and Installation guide for perl5.
=head1 SYNOPSIS
First, make sure you are installing an up-to-date version of Perl. If
you didn't get your Perl source from CPAN, check the latest version at
<URL:http://www.cpan.org/src/>.
The basic steps to build and install perl5 on a Unix system
with all the defaults are:
rm -f config.sh Policy.sh
sh Configure -de
make
make test
make install
# You may also wish to add these:
(cd /usr/include && h2ph *.h sys/*.h)
(installhtml --help)
(cd pod && make tex && <process the latex files>)
Each of these is explained in further detail below.
B<NOTE>: starting from the release 5.6.0, Perl uses a version
scheme where even-numbered subreleases (like 5.6 and 5.8) are stable
maintenance releases and odd-numbered subreleases (like 5.7 and 5.9) are
unstable development releases. Development releases should not be
used in production environments. Fixes and new features are first
carefully tested in development releases and only if they prove
themselves to be worthy will they be migrated to the maintenance
releases.
The above commands will install Perl to /usr/local (or some other
platform-specific directory -- see the appropriate file in hints/.)
If that's not okay with you, use
rm -f config.sh Policy.sh
sh Configure
make
make test
make install
For information on non-Unix systems, see the section on L<"Porting
information"> below.
If "make install" just says "`install' is up to date" or something
similar, you may be on a case-insensitive filesystems such as Mac's HFS+,
and you should say "make install-all". (This confusion is brought to you
by the Perl distribution having a file called INSTALL.)
If you have problems, corrections, or questions, please see
L<"Reporting Problems"> below.
For information on what's new in this release, see the
pod/perldelta.pod file. For more detailed information about specific
changes, see the Changes file.
=head1 DESCRIPTION
This document is written in pod format as an easy way to indicate its
structure. The pod format is described in pod/perlpod.pod, but you can
read it as is with any pager or editor. Headings and items are marked
by lines beginning with '='. The other mark-up used is
B<text> embolden text, used for switches, programs or commands
C<code> literal code
L<name> A link (cross reference) to name
Although most of the defaults are probably fine for most users,
you should probably at least skim through this entire document before
proceeding.
If you're building Perl on a non-Unix system, you should also read
the README file specific to your operating system, since this may
provide additional or different instructions for building Perl. There
are also README files for several flavors of Unix systems, such as
Solaris, HP-UX, and AIX; if you have one of those systems, you should
also read the README file specific to that system.
If there is a hint file for your system (in the hints/ directory) you
should also read that hint file for specific information for your
system. (Unixware users should use the svr4.sh or the svr5.sh hint file.)
Additional information is in the Porting/ directory.
=head1 WARNING: This version requires an extra step to build old extensions.
5.005_53 and later releases do not export unadorned
global symbols anymore. This means you may need to build rather old
extensions that have not been updated for the current naming convention
with:
perl Makefile.PL POLLUTE=1
Alternatively, you can enable CPP symbol pollution wholesale by
building perl itself with:
sh Configure -Accflags=-DPERL_POLLUTE
pod/perl56delta.pod contains more details about this.
=head1 WARNING: This version is not binary compatible with releases of
Perl prior to 5.9.0.
If you have built extensions (i.e. modules that include C code)
using an earlier version of Perl, you will need to rebuild and reinstall
those extensions.
Pure perl modules without XS or C code should continue to work fine
without reinstallation. See the discussions below on
L<"Coexistence with earlier versions of perl5"> and
L<"Upgrading from 5.005 or 5.6 to 5.8.0"> for more details.
The standard extensions supplied with Perl will be handled automatically.
On a related issue, old modules may possibly be affected by the
changes in the Perl language in the current release. Please see
pod/perldelta.pod (and the earlier pod/perl5Xdelta.pod) for a description of
what's changed. See your installed copy of the perllocal.pod
file for a (possibly incomplete) list of locally installed modules.
Also see CPAN::autobundle for one way to make a "bundle" of your
currently installed modules.
=head1 WARNING: This version requires a compiler that supports ANSI C.
Most C compilers are now ANSI-compliant. However, a few current
computers are delivered with an older C compiler expressly for
rebuilding the system kernel, or for some other historical reason.
Alternatively, you may have an old machine which was shipped before
ANSI compliance became widespread. Such compilers are not suitable
for building Perl.
If you find that your default C compiler is not ANSI-capable, but you
know that an ANSI-capable compiler is installed on your system, you
can tell F<Configure> to use the correct compiler by means of the
C<-Dcc=> command-line option -- see L<"gcc">.
If do not have an ANSI-capable compiler there are a couple of avenues
open to you:
=over 4
=item *
You may try obtaining GCC, available from GNU mirrors worldwide,
listed at <URL:http://www.gnu.org/order/ftp.html>. If, rather than
building gcc from source code, you locate a binary version configured
for your platform, be sure that it is compiled for the version of the
operating system that you are using.
=item *
You may purchase a commercial ANSI C compiler from your system
supplier or elsewhere. (Or your organization may already have
licensed such software -- ask your colleagues to find out how to
access it.) If there is a README file for your system in the Perl
distribution (for example, F<README.hpux>), it may contain advice on
suitable compilers.
=back
Although Perl can be compiled using a C++ compiler, the Configure script
does not work with some C++ compilers.
=head1 Space Requirements
The complete perl5 source tree takes up about 60 MB of disk space.
After completing make, it takes up roughly 100 MB, though the actual
total is likely to be quite system-dependent. The installation
directories need something on the order of 45 MB, though again that
value is system-dependent. A perl build with debug symbols and
-DDEBUGGING will require something on the order of 10 MB extra.
=head1 Start with a Fresh Distribution
If you have built perl before, you should clean out the build directory
with the command
make distclean
or
make realclean
The only difference between the two is that make distclean also removes
your old config.sh and Policy.sh files.
The results of a Configure run are stored in the config.sh and Policy.sh
files. If you are upgrading from a previous version of perl, or if you
change systems or compilers or make other significant changes, or if
you are experiencing difficulties building perl, you should probably
not re-use your old config.sh. Simply remove it
rm -f config.sh
If you wish to use your old config.sh, be especially attentive to the
version and architecture-specific questions and answers. For example,
the default directory for architecture-dependent library modules
includes the version name. By default, Configure will reuse your old
name (e.g. /opt/perl/lib/i86pc-solaris/5.003) even if you're running
Configure for a different version, e.g. 5.004. Yes, Configure should
probably check and correct for this, but it doesn't.
Similarly, if you used a shared libperl.so (see below) with version
numbers, you will probably want to adjust them as well.
Also, be careful to check your architecture name. For example, some
Linux distributions use i386, while others may use i486. If you build
it yourself, Configure uses the output of the arch command, which
might be i586 or i686 instead. If you pick up a precompiled binary, or
compile extensions on different systems, they might not all agree on
the architecture name.
In short, if you wish to use your old config.sh, I recommend running
Configure interactively rather than blindly accepting the defaults.
If your reason to reuse your old config.sh is to save your particular
installation choices, then you can probably achieve the same effect by
using the Policy.sh file. See the section on L<"Site-wide Policy
settings"> below. If you wish to start with a fresh distribution, you
also need to remove any old Policy.sh files you may have with
rm -f Policy.sh
=head1 Run Configure
Configure will figure out various things about your system. Some
things Configure will figure out for itself, other things it will ask
you about. To accept the default, just press RETURN. The default is
almost always okay. It is normal for some things to be "NOT found",
since Configure often searches for many different ways of performing
the same function.
At any Configure prompt, you can type &-d and Configure will use the
defaults from then on.
After it runs, Configure will perform variable substitution on all the
*.SH files and offer to run make depend.
=head2 Disabling older versions of Perl
Configure will search for binary compatible versions of previously
installed perl binaries in the tree that is specified as target tree
and these will be used by the perl being built.
To disable use of older perl modules, even completely valid pure perl
modules, you can specify to not include the pathes found:
sh Configure -Dinc_version_list=none ...
When using the newer perl, you can add these pathes again in the
$PERL5LIB environment variable or with perl's -I runtime option.
=head2 Altering config.sh variables for C compiler switches etc.
For most users, all of the Configure defaults are fine. Configure
also has several convenient options which are described below.
However, if Configure doesn't have an option to do what you want,
you can change Configure variables after the platform hints have been
run, by using Configure's -A switch. For example, here's how to add
a couple of extra flags to C compiler invocations:
sh Configure -Accflags="-DPERL_Y2KWARN -DPERL_POLLUTE_MALLOC"
For more help on Configure switches, run:
sh Configure -h
=head2 Building Perl outside of the source directory
Sometimes it is desirable to build Perl in a directory different from
where the sources are, for example if you want to keep your sources
read-only, or if you want to share the sources between different binary
architectures. You can do this (if your file system supports symbolic
links) by
mkdir /tmp/perl/build/directory
cd /tmp/perl/build/directory
sh /path/to/perl/source/Configure -Dmksymlinks ...
This will create in /tmp/perl/build/directory a tree of symbolic links
pointing to files in /path/to/perl/source. The original files are left
unaffected. After Configure has finished you can just say
make all test
and Perl will be built and tested, all in /tmp/perl/build/directory.
=head2 Common Configure options
Configure supports a number of useful options. Run B<Configure -h> to
get a listing. See the Porting/Glossary file for a complete list of
Configure variables you can set and their definitions.
=over 4
=item gcc
To compile with gcc you should run
sh Configure -Dcc=gcc
This is the preferred way to specify gcc (or another alternative
compiler) so that the hints files can set appropriate defaults.
=item Installation prefix
By default, for most systems, perl will be installed in
/usr/local/{bin, lib, man}. (See L<"Installation Directories">
and L<"Coexistence with earlier versions of perl5"> below for
further details.)
You can specify a different 'prefix' for the default installation
directory, when Configure prompts you or by using the Configure command
line option -Dprefix='/some/directory', e.g.
sh Configure -Dprefix=/opt/perl
If your prefix contains the string "perl", then the suggested
directory structure is simplified. For example, if you use
prefix=/opt/perl, then Configure will suggest /opt/perl/lib instead of
/opt/perl/lib/perl5/. Again, see L<"Installation Directories"> below
for more details. Do not include a trailing slash, (i.e. /opt/perl/)
or you may experience odd test failures.
NOTE: You must not specify an installation directory that is the same
as or below your perl source directory. If you do, installperl will
attempt infinite recursion.
=item /usr/bin/perl
It may seem obvious, but Perl is useful only when users can easily
find it. It's often a good idea to have both /usr/bin/perl and
/usr/local/bin/perl be symlinks to the actual binary. Be especially
careful, however, not to overwrite a version of perl supplied by your
vendor unless you are sure you know what you are doing. If you insist
on replacing your vendor's perl, useful information on how it was
configured may be found with
perl -V:config_args
(Check the output carefully, however, since this doesn't preserve
spaces in arguments to Configure. For that, you have to look
carefully at config_arg1, config_arg2, etc.)
By default, Configure will not try to link /usr/bin/perl to
the current version of perl. You can turn on that behavior by running
Configure -Dinstallusrbinperl
or by answering 'yes' to the appropriate Configure prompt.
(Note that before perl 5.8.1, the default behavior was to create
or overwrite /usr/bin/perl even if it already existed.)
In any case, system administrators are strongly encouraged to
put (symlinks to) perl and its accompanying utilities, such as perldoc,
into a directory typically found along a user's PATH, or in another
obvious and convenient place.
=item Overriding an old config.sh
If you want to use your old config.sh but override some of the items
with command line options, you need to use B<Configure -O>.
=back
If you are willing to accept all the defaults, and you want terse
output, you can run
sh Configure -des
Note: for development releases (odd subreleases, like 5.9, as opposed
to maintenance releases which have even subreleases, like 5.6 and 5.8)
if you want to use Configure -d, you will also need to supply -Dusedevel
to Configure, because the default answer to the question "do you really
want to Configure a development version?" is "no". The -Dusedevel
skips that sanity check.
For example for my Solaris system, I usually use
sh Configure -Dprefix=/opt/perl -Doptimize='-xpentium -xO4' -des
=head2 GNU-style configure
If you prefer the GNU-style configure command line interface, you can
use the supplied configure.gnu command, e.g.
CC=gcc ./configure.gnu
The configure.gnu script emulates a few of the more common configure
options. Try
./configure.gnu --help
for a listing.
(The file is called configure.gnu to avoid problems on systems
that would not distinguish the files "Configure" and "configure".)
See L<Cross-compilation> below for information on cross-compiling.
=head2 Installation Directories
The installation directories can all be changed by answering the
appropriate questions in Configure. For convenience, all the
installation questions are near the beginning of Configure.
Do not include trailing slashes on directory names.
I highly recommend running Configure interactively to be sure it puts
everything where you want it. At any point during the Configure
process, you can answer a question with &-d and Configure will use
the defaults from then on. Alternatively, you can
grep '^install' config.sh
after Configure has run to verify the installation paths.
The defaults are intended to be reasonable and sensible for most
people building from sources. Those who build and distribute binary
distributions or who export perl to a range of systems will probably
need to alter them. If you are content to just accept the defaults,
you can safely skip the next section.
The directories set up by Configure fall into three broad categories.
=over 4
=item Directories for the perl distribution
By default, Configure will use the following directories for 5.9.0.
$version is the full perl version number, including subversion, e.g.
5.9.0 or 5.9.1, and $archname is a string like sun4-sunos,
determined by Configure. The full definitions of all Configure
variables are in the file Porting/Glossary.
Configure variable Default value
$prefix /usr/local
$bin $prefix/bin
$scriptdir $prefix/bin
$privlib $prefix/lib/perl5/$version
$archlib $prefix/lib/perl5/$version/$archname
$man1dir $prefix/man/man1
$man3dir $prefix/man/man3
$html1dir (none)
$html3dir (none)
Actually, Configure recognizes the SVR3-style
/usr/local/man/l_man/man1 directories, if present, and uses those
instead. Also, if $prefix contains the string "perl", the library
directories are simplified as described below. For simplicity, only
the common style is shown here.
=item Directories for site-specific add-on files
After perl is installed, you may later wish to add modules (e.g. from
CPAN) or scripts. Configure will set up the following directories to
be used for installing those add-on modules and scripts.
Configure variable Default value
$siteprefix $prefix
$sitebin $siteprefix/bin
$sitescript $siteprefix/bin
$sitelib $siteprefix/lib/perl5/site_perl/$version
$sitearch $siteprefix/lib/perl5/site_perl/$version/$archname
$siteman1dir $siteprefix/man/man1
$siteman3dir $siteprefix/man/man3
$sitehtml1dir (none)
$sitehtml3dir (none)
By default, ExtUtils::MakeMaker will install architecture-independent
modules into $sitelib and architecture-dependent modules into $sitearch.
=item Directories for vendor-supplied add-on files
Lastly, if you are building a binary distribution of perl for
distribution, Configure can optionally set up the following directories
for you to use to distribute add-on modules.
Configure variable Default value
$vendorprefix (none)
(The next ones are set only if vendorprefix is set.)
$vendorbin $vendorprefix/bin
$vendorscript $vendorprefix/bin
$vendorlib $vendorprefix/lib/perl5/vendor_perl/$version
$vendorarch $vendorprefix/lib/perl5/vendor_perl/$version/$archname
$vendorman1dir $vendorprefix/man/man1
$vendorman3dir $vendorprefix/man/man3
$vendorhtml1dir (none)
$vendorhtml3dir (none)
These are normally empty, but may be set as needed. For example,
a vendor might choose the following settings:
$prefix /usr
$siteprefix /usr/local
$vendorprefix /usr
This would have the effect of setting the following:
$bin /usr/bin
$scriptdir /usr/bin
$privlib /usr/lib/perl5/$version
$archlib /usr/lib/perl5/$version/$archname
$man1dir /usr/man/man1
$man3dir /usr/man/man3
$sitebin /usr/local/bin
$sitescript /usr/local/bin
$sitelib /usr/local/lib/perl5/site_perl/$version
$sitearch /usr/local/lib/perl5/site_perl/$version/$archname
$siteman1dir /usr/local/man/man1
$siteman3dir /usr/local/man/man3
$vendorbin /usr/bin
$vendorscript /usr/bin
$vendorlib /usr/lib/perl5/vendor_perl/$version
$vendorarch /usr/lib/perl5/vendor_perl/$version/$archname
$vendorman1dir /usr/man/man1
$vendorman3dir /usr/man/man3
Note how in this example, the vendor-supplied directories are in the
/usr hierarchy, while the directories reserved for the end-user are in
the /usr/local hierarchy.
The entire installed library hierarchy is installed in locations with
version numbers, keeping the installations of different versions distinct.
However, later installations of Perl can still be configured to search the
installed libraries corresponding to compatible earlier versions.
See L<"Coexistence with earlier versions of perl5"> below for more details
on how Perl can be made to search older version directories.
Of course you may use these directories however you see fit. For
example, you may wish to use $siteprefix for site-specific files that
are stored locally on your own disk and use $vendorprefix for
site-specific files that are stored elsewhere on your organization's
network. One way to do that would be something like
sh Configure -Dsiteprefix=/usr/local -Dvendorprefix=/usr/share/perl
=item otherlibdirs
As a final catch-all, Configure also offers an $otherlibdirs
variable. This variable contains a colon-separated list of additional
directories to add to @INC. By default, it will be empty.
Perl will search these directories (including architecture and
version-specific subdirectories) for add-on modules and extensions.
For example, if you have a bundle of perl libraries from a previous
installation, perhaps in a strange place:
Configure -Dotherlibdirs=/usr/lib/perl5/site_perl/5.8.1
=item APPLLIB_EXP
There is one other way of adding paths to @INC at perl build time, and
that is by setting the APPLLIB_EXP C pre-processor token to a colon-
separated list of directories, like this
sh Configure -Accflags='-DAPPLLIB_EXP=\"/usr/libperl\"'
The directories defined by APPLLIB_EXP get added to @INC I<first>,
ahead of any others, and so provide a way to override the standard perl
modules should you, for example, want to distribute fixes without
touching the perl distribution proper. And, like otherlib dirs,
version and architecture specific subdirectories are also searched, if
present, at run time. Of course, you can still search other @INC
directories ahead of those in APPLLIB_EXP by using any of the standard
run-time methods: $PERLLIB, $PERL5LIB, -I, use lib, etc.
=item Man Pages
In versions 5.005_57 and earlier, the default was to store module man
pages in a version-specific directory, such as
/usr/local/lib/perl5/$version/man/man3. The default for 5.005_58 and
after is /usr/local/man/man3 so that most users can find the man pages
without resetting MANPATH.
You can continue to use the old default from the command line with
sh Configure -Dman3dir=/usr/local/lib/perl5/5.9.0/man/man3
Some users also prefer to use a .3pm suffix. You can do that with
sh Configure -Dman3ext=3pm
Again, these are just the defaults, and can be changed as you run
Configure.
=item HTML pages
Currently, the standard perl installation does not do anything with
HTML documentation, but that may change in the future. Further, some
add-on modules may wish to install HTML documents. The html Configure
variables listed above are provided if you wish to specify where such
documents should be placed. The default is "none", but will likely
eventually change to something useful based on user feedback.
=back
Some users prefer to append a "/share" to $privlib and $sitelib
to emphasize that those directories can be shared among different
architectures.
Note that these are just the defaults. You can actually structure the
directories any way you like. They don't even have to be on the same
filesystem.
Further details about the installation directories, maintenance and
development subversions, and about supporting multiple versions are
discussed in L<"Coexistence with earlier versions of perl5"> below.
If you specify a prefix that contains the string "perl", then the
library directory structure is slightly simplified. Instead of
suggesting $prefix/lib/perl5/, Configure will suggest $prefix/lib.
Thus, for example, if you Configure with
-Dprefix=/opt/perl, then the default library directories for 5.9.0 are
Configure variable Default value
$privlib /opt/perl/lib/5.9.0
$archlib /opt/perl/lib/5.9.0/$archname
$sitelib /opt/perl/lib/site_perl/5.9.0
$sitearch /opt/perl/lib/site_perl/5.9.0/$archname
=head2 Changing the installation directory
Configure distinguishes between the directory in which perl (and its
associated files) should be installed and the directory in which it
will eventually reside. For most sites, these two are the same; for
sites that use AFS, this distinction is handled automatically.
However, sites that use software such as depot to manage software
packages, or users building binary packages for distribution may also
wish to install perl into a different directory and use that
management software to move perl to its final destination. This
section describes how to do that.
Suppose you want to install perl under the /tmp/perl5 directory. You
could edit config.sh and change all the install* variables to point to
/tmp/perl5 instead of /usr/local, or you could simply use the
following command line:
sh Configure -Dinstallprefix=/tmp/perl5
(replace /tmp/perl5 by a directory of your choice).
Beware, though, that if you go to try to install new add-on
modules, they too will get installed in under '/tmp/perl5' if you
follow this example. The next section shows one way of dealing with
that problem.
=head2 Creating an installable tar archive
If you need to install perl on many identical systems, it is
convenient to compile it once and create an archive that can be
installed on multiple systems. Suppose, for example, that you want to
create an archive that can be installed in /opt/perl.
Here's one way to do that:
# Set up to install perl into a different directory,
# e.g. /tmp/perl5 (see previous part).
sh Configure -Dinstallprefix=/tmp/perl5 -Dprefix=/opt/perl -des
make
make test
make install # This will install everything into /tmp/perl5.
cd /tmp/perl5
# Edit $archlib/Config.pm and $archlib/.packlist to change all the
# install* variables back to reflect where everything will
# really be installed. (That is, change /tmp/perl5 to /opt/perl
# everywhere in those files.)
# Check the scripts in $scriptdir to make sure they have the correct
# #!/wherever/perl line.
tar cvf ../perl5-archive.tar .
# Then, on each machine where you want to install perl,
cd /opt/perl # Or wherever you specified as $prefix
tar xvf perl5-archive.tar
Alternatively, the DESTDIR variable is honored during C<make install>.
The DESTDIR is automatically prepended to all the installation paths
(and there is no need to edit anything). With DESTDIR, the above
example can we written as:
sh Configure -Dprefix=/opt/perl -des
make
make test
make install DESTDIR=/tmp/perl5
cd /tmp/perl5/opt/perl
tar cvf /tmp/perl5-archive.tar .
=head2 Site-wide Policy settings
After Configure runs, it stores a number of common site-wide "policy"
answers (such as installation directories and the local perl contact
person) in the Policy.sh file. If you want to build perl on another
system using the same policy defaults, simply copy the Policy.sh file
to the new system and Configure will use it along with the appropriate
hint file for your system.
Alternatively, if you wish to change some or all of those policy
answers, you should
rm -f Policy.sh
to ensure that Configure doesn't re-use them.
Further information is in the Policy_sh.SH file itself.
If the generated Policy.sh file is unsuitable, you may freely edit it
to contain any valid shell commands. It will be run just after the
platform-specific hints files.
=head2 Configure-time Options
There are several different ways to Configure and build perl for your
system. For most users, the defaults are sensible and will work.
Some users, however, may wish to further customize perl. Here are
some of the main things you can change.
=head2 Threads
On some platforms, perl can be compiled with
support for threads. To enable this, run
sh Configure -Dusethreads
Currently, you need to specify -Dusethreads on the Configure command
line so that the hint files can make appropriate adjustments.
The default is to compile without thread support.
Perl has two different internal threads implementations. The current
model (available internally since 5.6, and as a user-level module
since 5.8) is called interpreter-based implementation (ithreads),
with one interpreter per thread, and explicit sharing of data.
The 5.005 version (5005threads) is considered obsolete, buggy, and
unmaintained.
By default, Configure selects ithreads if -Dusethreads is specified.
(You need to also use the PerlIO layer, explained later, if you decide
to use ithreads, to guarantee the good interworking of threads and I/O.)
However, if you wish, you can select the unsupported old 5005threads behavior
sh Configure -Dusethreads -Duse5005threads
If you decide to use ithreads, the 'threads' module allows their use,
and the 'Thread' module offers an interface to both 5005threads and
ithreads (whichever has been configured).
When building threaded for certain library calls like the getgr*() and
the getpw*() there is a dynamically sized result buffer: the buffer
starts small but Perl will keep growing the buffer until the result fits.
To get a fixed upper limit you will have to recompile Perl with
PERL_REENTRANT_MAXSIZE defined to be the number of bytes you want.
One way to do this is to run Configure with
C<-Accflags=-DPERL_REENTRANT_MAXSIZE=65536>
=head2 Large file support.
Since Perl 5.6.0, Perl has supported large files (files larger than
2 gigabytes), and in many common platforms like Linux or Solaris this
support is on by default.
This is both good and bad. It is good in that you can use large files,
seek(), stat(), and -s them. It is bad in that if you are interfacing Perl
using some extension, the components you are connecting to must also
be large file aware: if Perl thinks files can be large but the other
parts of the software puzzle do not understand the concept, bad things
will happen. One popular extension suffering from this ailment is the
Apache extension mod_perl.
There's also one known limitation with the current large files
implementation: unless you also have 64-bit integers (see the next
section), you cannot use the printf/sprintf non-decimal integer
formats like C<%x> to print filesizes. You can use C<%d>, though.
=head2 64 bit support.
If your platform does not have 64 bits natively, but can simulate them
with compiler flags and/or C<long long> or C<int64_t>, you can build a
perl that uses 64 bits.
There are actually two modes of 64-bitness: the first one is achieved
using Configure -Duse64bitint and the second one using Configure
-Duse64bitall. The difference is that the first one is minimal and
the second one maximal. The first works in more places than the second.
The C<use64bitint> does only as much as is required to get 64-bit
integers into Perl (this may mean, for example, using "long longs")
while your memory may still be limited to 2 gigabytes (because your
pointers could still be 32-bit). Note that the name C<64bitint> does
not imply that your C compiler will be using 64-bit C<int>s (it might,
but it doesn't have to): the C<use64bitint> means that you will be
able to have 64 bits wide scalar values.
The C<use64bitall> goes all the way by attempting to switch also
integers (if it can), longs (and pointers) to being 64-bit. This may
create an even more binary incompatible Perl than -Duse64bitint: the
resulting executable may not run at all in a 32-bit box, or you may
have to reboot/reconfigure/rebuild your operating system to be 64-bit
aware.
Natively 64-bit systems like Alpha and Cray need neither -Duse64bitint
nor -Duse64bitall.
NOTE: 64-bit support is still experimental on most platforms.
Existing support only covers the LP64 data model. In particular, the
LLP64 data model is not yet supported. 64-bit libraries and system
APIs on many platforms have not stabilized--your mileage may vary.
=head2 Long doubles
In some systems you may be able to use long doubles to enhance the
range and precision of your double precision floating point numbers
(that is, Perl's numbers). Use Configure -Duselongdouble to enable
this support (if it is available).
=head2 "more bits"
You can "Configure -Dusemorebits" to turn on both the 64-bit support
and the long double support.
=head2 Selecting File IO mechanisms
Executive summary: as of Perl 5.8, you should use the default "PerlIO"
as the IO mechanism unless you have a good reason not to.
In more detail: previous versions of perl used the standard IO
mechanisms as defined in stdio.h. Versions 5.003_02 and later of perl
introduced alternate IO mechanisms via a "PerlIO" abstraction, but up
until and including Perl 5.6, the stdio mechanism was still the default
and the only supported mechanism.
Starting from Perl 5.8, the default mechanism is to use the PerlIO
abstraction, because it allows better control of I/O mechanisms,
instead of having to work with (often, work around) vendors' I/O
implementations.
This PerlIO abstraction can be (but again, unless you know what you
are doing, should not be) disabled either on the Configure command
line with
sh Configure -Uuseperlio
or interactively at the appropriate Configure prompt.
With the PerlIO abstraction layer, there is another possibility for
the underlying IO calls, AT&T's "sfio". This has superior performance
to stdio.h in many cases, and is extensible by the use of "discipline"
modules ("Native" PerlIO has them too). Sfio currently only builds on
a subset of the UNIX platforms perl supports. Because the data
structures are completely different from stdio, perl extension modules
or external libraries may not work. This configuration exists to
allow these issues to be worked on.
This option requires the 'sfio' package to have been built and installed.
The latest sfio is available from http://www.research.att.com/sw/tools/sfio/
You select this option by
sh Configure -Duseperlio -Dusesfio
If you have already selected -Duseperlio, and if Configure detects
that you have sfio, then sfio will be the default suggested by
Configure.
Note: On some systems, sfio's iffe configuration script fails to
detect that you have an atexit function (or equivalent). Apparently,
this is a problem at least for some versions of Linux and SunOS 4.
Configure should detect this problem and warn you about problems with
_exit vs. exit. If you have this problem, the fix is to go back to
your sfio sources and correct iffe's guess about atexit.
=head2 Algorithmic Complexity Attacks on Hashes
In Perls 5.8.0 and earlier it was easy to create degenerate hashes.
Processing such hashes would consume large amounts of CPU time,
enabling a "Denial of Service" attack against Perl. Such hashes may be
a problem for example for mod_perl sites, sites with Perl CGI scripts
and web services, that process data originating from external sources.
In Perl 5.8.1 a security feature was introduced to make it harder
to create such degenerate hashes.
Because of this feature the keys(), values(), and each() functions may
return the hash elements in different order between different runs of
Perl even with the same data. One can still revert to the old
repeatable order by setting the environment variable PERL_HASH_SEED,
see L<perlrun/PERL_HASH_SEED>. Another option is to add
-DUSE_HASH_SEED_EXPLICIT to the compilation flags (for example by
using C<Configure -Accflags=-DUSE_HAS_SEED_EXPLICIT>), in which case
one has to explicitly set the PERL_HASH_SEED environment variable to
enable the security feature, or by adding -DNO_HASH_SEED to the compilation
flags to completely disable the randomisation feature.
B<Perl has never guaranteed any ordering of the hash keys>, and the
ordering has already changed several times during the lifetime of
Perl 5. Also, the ordering of hash keys has always been, and
continues to be, affected by the insertion order.
Note that because of this randomisation for example the Data::Dumper
results will be different between different runs of Perl since
Data::Dumper by default dumps hashes "unordered". The use of the
Data::Dumper C<Sortkeys> option is recommended.
=head2 SOCKS
Perl can be configured to be 'socksified', that is, to use the SOCKS
TCP/IP proxy protocol library. SOCKS is used to give applications
access to transport layer network proxies. Perl supports only SOCKS
Version 5. You can find more about SOCKS from http://www.socks.nec.com/
=head2 Dynamic Loading
By default, Configure will compile perl to use dynamic loading if
your system supports it. If you want to force perl to be compiled
statically, you can either choose this when Configure prompts you or
you can use the Configure command line option -Uusedl.
=head2 Building a shared Perl library
Currently, for most systems, the main perl executable is built by
linking the "perl library" libperl.a with perlmain.o, your static
extensions (usually just DynaLoader.a) and various extra libraries,
such as -lm.
On some systems that support dynamic loading, it may be possible to
replace libperl.a with a shared libperl.so. If you anticipate building
several different perl binaries (e.g. by embedding libperl into
different programs, or by using the optional compiler extension), then
you might wish to build a shared libperl.so so that all your binaries
can share the same library.
The disadvantages are that there may be a significant performance
penalty associated with the shared libperl.so, and that the overall
mechanism is still rather fragile with respect to different versions
and upgrades.
In terms of performance, on my test system (Solaris 2.5_x86) the perl
test suite took roughly 15% longer to run with the shared libperl.so.
Your system and typical applications may well give quite different
results.
The default name for the shared library is typically something like
libperl.so.3.2 (for Perl 5.003_02) or libperl.so.302 or simply
libperl.so. Configure tries to guess a sensible naming convention
based on your C library name. Since the library gets installed in a
version-specific architecture-dependent directory, the exact name
isn't very important anyway, as long as your linker is happy.
For some systems (mostly SVR4), building a shared libperl is required
for dynamic loading to work, and hence is already the default.
You can elect to build a shared libperl by
sh Configure -Duseshrplib
To build a shared libperl, the environment variable controlling shared
library search (LD_LIBRARY_PATH in most systems, DYLD_LIBRARY_PATH for
NeXTSTEP/OPENSTEP/Darwin, LIBRARY_PATH for BeOS, LD_LIBRARY_PATH/SHLIB_PATH
for HP-UX, LIBPATH for AIX, PATH for Cygwin) must be set up to include
the Perl build directory because that's where the shared libperl will
be created. Configure arranges makefile to have the correct shared
library search settings. You can find the name of the environment
variable Perl thinks works in your your system by
grep ldlibpthname config.sh
However, there are some special cases where manually setting the
shared library path might be required. For example, if you want to run
something like the following with the newly-built but not-yet-installed
./perl:
cd t; ./perl misc/failing_test.t
or
./perl -Ilib ~/my_mission_critical_test
then you need to set up the shared library path explicitly.
You can do this with
LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
for Bourne-style shells, or
setenv LD_LIBRARY_PATH `pwd`
for Csh-style shells. (This procedure may also be needed if for some
unexpected reason Configure fails to set up makefile correctly.) (And
again, it may be something other than LD_LIBRARY_PATH for you, see above.)
You can often recognize failures to build/use a shared libperl from error
messages complaining about a missing libperl.so (or libperl.sl in HP-UX),
for example:
18126:./miniperl: /sbin/loader: Fatal Error: cannot map libperl.so
There is also an potential problem with the shared perl library if you
want to have more than one "flavor" of the same version of perl (e.g.
with and without -DDEBUGGING). For example, suppose you build and