forked from schacon/perl
/
INSTALL
2569 lines (1915 loc) · 99.4 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
If you read this file _as_is_, just ignore the funny characters you see.
It is written in the POD format (see pod/perlpod.pod) which is specially
designed to be readable as is.
=head1 NAME
Install - Build and Installation guide for perl 5.
=head1 SYNOPSIS
First, make sure you have an up-to-date version of Perl. If you
didn't get your Perl source from CPAN, check the latest version at
http://www.cpan.org/src/. Perl uses a version scheme where even-numbered
subreleases (like 5.8.x and 5.10.x) are stable maintenance releases and
odd-numbered subreleases (like 5.7.x and 5.9.x) 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 basic steps to build and install perl 5 on a Unix system with all
the defaults are to run, from a freshly unpacked source tree:
sh Configure -de
make
make test
make install
Each of these is explained in further detail below.
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, you can run Configure interactively, by
just typing "sh Configure" (without the -de args). You can also specify
any prefix location by adding "-Dprefix='/some/dir'" to Configure's args.
To explicitly name the perl binary, use the command
"make install PERLNAME=myperl".
Building perl from source requires an ANSI compliant C-Compiler.
A minimum of C89 is required. Some features available in C99 will
be probed for and used when found. The perl build process does not
rely on anything more than C89.
These options, and many more, are explained in further detail below.
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 information about how to find more
specific detail about 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
F<file> A filename
Although most of the defaults are probably fine for most users,
you should probably at least skim through this document before
proceeding.
In addition to this file, check if there is a README file specific to
your operating system, since it may provide additional or different
instructions for building Perl. If there is a hint file for your
system (in the hints/ directory) you might also want to read it
for even more information.
For additional information about porting Perl, see the section on
L<"Porting information"> below, and look at the files in the Porting/
directory.
=head1 PRELIMINARIES
=head2 Changes and Incompatibilities
Please see pod/perldelta.pod for a description of the changes and
potential incompatibilities introduced with this release. A few of
the most important issues are listed below, but you should refer
to pod/perldelta.pod for more detailed information.
B<WARNING:> This version is not binary compatible with prior releases of Perl.
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 discussion below on
L<"Coexistence with earlier versions of perl 5"> 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 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 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.
The results of a Configure run are stored in the config.sh and Policy.sh
files.
=head2 Common Configure options
Configure supports a number of useful options. Run
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 C compiler
To compile with gcc, if it's not the default compiler on your
system, you should run
sh Configure -Dcc=gcc
This is the preferred way to specify gcc (or any 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 perl 5"> 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.
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 Building a development release
For development releases (odd subreleases, like 5.9.x) 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.
=back
If you are willing to accept all the defaults, and you want terse
output, you can run
sh Configure -des
=head2 Altering Configure variables for C compiler switches etc.
For most users, most of the Configure defaults are fine, or can easily
be set on the Configure command line. 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_EXTERNAL_GLOB -DNO_HASH_SEED"
To clarify, those ccflags values are not Configure options; if passed to
Configure directly, they won't do anything useful (they will define a
variable in config.sh, but without taking any action based upon it).
But when passed to the compiler, those flags will activate #ifdefd code.
For more help on Configure switches, run
sh Configure -h
=head2 Major Configure-time Build 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.
=head3 Threads
On some platforms, perl can be compiled with support for threads. To
enable this, run
sh Configure -Dusethreads
The default is to compile without thread support.
Perl used to have 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 (deprecated) 5.005 version
(5005threads) was removed for release 5.10.
The 'threads' module is for use with the ithreads implementation. The
'Thread' module emulates the old 5005threads interface on top of the current
ithreads model.
When using threads, perl uses a dynamically-sized buffer for some of
the thread-safe library calls, such as those in the getpw*() family.
This buffer starts small, but it will keep growing until the result
fits. To get a fixed upper limit, you should compile 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>.
=head3 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.
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.
If you want to compile perl without large file support, use
sh Configure -Uuselargefiles
=head3 64 bit support
If your platform does not run natively at 64 bits, 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> option 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> simply means that
you will be able to have 64 bit-wide scalar values.
The C<use64bitall> option goes all the way by attempting to switch
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 need neither -Duse64bitint nor -Duse64bitall.
On these systems, it might be the default compilation mode, and there
is currently no guarantee that passing no use64bitall option to the
Configure process will build a 32bit perl. Implementing -Duse32bit*
options is planned for a future release of perl.
=head3 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).
=head3 "more bits"
You can "Configure -Dusemorebits" to turn on both the 64-bit support
and the long double support.
=head3 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. A visible side effect of this was that
the keys(), values(), and each() functions may return the hash elements
in different order between different runs of Perl even with the same
data. It also had unintended binary incompatibility issues with
certain modules compiled against Perl 5.8.0.
In Perl 5.8.2 an improved scheme was introduced. Hashes will return
elements in the same order as Perl 5.8.0 by default. On a hash by hash
basis, if pathological data is detected during a hash key insertion,
then that hash will switch to an alternative random hash seed. As
adding keys can always dramatically change returned hash element order,
existing programs will not be affected by this, unless they
specifically test for pre-recorded hash return order for contrived
data. (eg the list of keys generated by C<map {"\0"x$_} 0..15> trigger
randomisation) In effect the new implementation means that 5.8.1 scheme
is only being used on hashes which are under attack.
One can still revert to the old guaranteed repeatable order (and be
vulnerable to attack by wily crackers) 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_HASH_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.
=head3 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. The corresponding Configure option is -Dusesocks.
You can find more about SOCKS from wikipedia at
L<http://en.wikipedia.org/wiki/SOCKS>.
=head3 Dynamic Loading
By default, Configure will compile perl to use dynamic loading.
If you want to force perl to be compiled completely
statically, you can either choose this when Configure prompts you or
you can use the Configure command line option -Uusedl.
With this option, you won't be able to use any new extension
(XS) module without recompiling perl itself.
=head3 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, and various extra libraries, such as -lm.
On 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.5.8.8 (for Perl 5.8.8), or libperl.so.588, 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.
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 -MTestInit 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
install a standard Perl 5.10.0 with a shared library. Then, suppose you
try to build Perl 5.10.0 with -DDEBUGGING enabled, but everything else
the same, including all the installation directories. How can you
ensure that your newly built perl will link with your newly built
libperl.so.8 rather with the installed libperl.so.8? The answer is
that you might not be able to. The installation directory is encoded
in the perl binary with the LD_RUN_PATH environment variable (or
equivalent ld command-line option). On Solaris, you can override that
with LD_LIBRARY_PATH; on Linux, you can only override at runtime via
LD_PRELOAD, specifying the exact filename you wish to be used; and on
Digital Unix, you can override LD_LIBRARY_PATH by setting the
_RLD_ROOT environment variable to point to the perl build directory.
In other words, it is generally not a good idea to try to build a perl
with a shared library if $archlib/CORE/$libperl already exists from a
previous build.
A good workaround is to specify a different directory for the
architecture-dependent library for your -DDEBUGGING version of perl.
You can do this by changing all the *archlib* variables in config.sh to
point to your new architecture-dependent library.
=head3 Environment access
Perl often needs to write to the program's environment, such as when C<%ENV>
is assigned to. Many implementations of the C library function C<putenv()>
leak memory, so where possible perl will manipulate the environment directly
to avoid these leaks. The default is now to perform direct manipulation
whenever perl is running as a stand alone interpreter, and to call the safe
but potentially leaky C<putenv()> function when the perl interpreter is
embedded in another application. You can force perl to always use C<putenv()>
by compiling with C<-Accflags="-DPERL_USE_SAFE_PUTENV">, see section
L</"Altering Configure variables for C compiler switches etc.">.
You can force an embedded perl to use direct manipulation by setting
C<PL_use_safe_putenv = 0;> after the C<perl_construct()> call.
=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. 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.13.4.
$version is the full perl version number, including subversion, e.g.
5.13.4 or 5.9.5, 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
$prefixexp /usr/local
$binexp $prefixexp/bin
$scriptdirexp $prefixexp/bin
$privlibexp $prefixexp/lib/perl5/$version
$archlibexp $prefixexp/lib/perl5/$version/$archname
$man1direxp $prefixexp/man/man1
$man3direxp $prefixexp/man/man3
$html1direxp (none)
$html3direxp (none)
$prefixexp is generated from $prefix, with ~ expansion done to convert home
directories into absolute paths. Similarly for the other variables listed. As
file system calls do not do this, you should always reference the ...exp
variables, to support users who build perl in their home directory.
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
$siteprefixexp $prefixexp
$sitebinexp $siteprefixexp/bin
$sitescriptexp $siteprefixexp/bin
$sitelibexp $siteprefixexp/lib/perl5/site_perl/$version
$sitearchexp $siteprefixexp/lib/perl5/site_perl/$version/$archname
$siteman1direxp $siteprefixexp/man/man1
$siteman3direxp $siteprefixexp/man/man3
$sitehtml1direxp (none)
$sitehtml3direxp (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
$vendorprefixexp (none)
(The next ones are set only if vendorprefix is set.)
$vendorbinexp $vendorprefixexp/bin
$vendorscriptexp $vendorprefixexp/bin
$vendorlibexp
$vendorprefixexp/lib/perl5/vendor_perl/$version
$vendorarchexp
$vendorprefixexp/lib/perl5/vendor_perl/$version/$archname
$vendorman1direxp $vendorprefixexp/man/man1
$vendorman3direxp $vendorprefixexp/man/man3
$vendorhtml1direxp (none)
$vendorhtml3direxp (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:
$binexp /usr/bin
$scriptdirexp /usr/bin
$privlibexp /usr/lib/perl5/$version
$archlibexp /usr/lib/perl5/$version/$archname
$man1direxp /usr/man/man1
$man3direxp /usr/man/man3
$sitebinexp /usr/local/bin
$sitescriptexp /usr/local/bin
$sitelibexp /usr/local/lib/perl5/site_perl/$version
$sitearchexp /usr/local/lib/perl5/site_perl/$version/$archname
$siteman1direxp /usr/local/man/man1
$siteman3direxp /usr/local/man/man3
$vendorbinexp /usr/bin
$vendorscriptexp /usr/bin
$vendorlibexp /usr/lib/perl5/vendor_perl/$version
$vendorarchexp /usr/lib/perl5/vendor_perl/$version/$archname
$vendorman1direxp /usr/man/man1
$vendorman3direxp /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 perl 5"> 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 usesitecustomize
Run-time customization of @INC can be enabled with:
sh Configure -Dusesitecustomize
which will define USE_SITECUSTOMIZE and $Config{usesitecustomize}.
When enabled, this makes perl run F<$sitelibexp/sitecustomize.pl> before
anything else. This script can then be set up to add additional
entries to @INC.
=item Man Pages
By default, man pages will be installed in $man1dir and $man3dir, which
are normally /usr/local/man/man1 and /usr/local/man/man3. If you
want to use a .3pm suffix for perl man pages, you can do that with
sh Configure -Dman3ext=3pm
=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 perl 5"> 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 package management software such as rpm or
dpkg, or users building binary packages for distribution may also
wish to install perl into a different directory before moving perl
to its final destination. There are two ways to do that:
=over 4
=item installprefix
To install perl under the /tmp/perl5 directory, 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. That's why it's usually better to use DESTDIR,
as shown in the next section.
=item DESTDIR
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. One way to do that is by
using the DESTDIR variable during C<make install>. The DESTDIR is
automatically prepended to all the installation paths. Thus you
simply do:
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 .
=back
=head2 Relocatable @INC
To create a relocatable perl tree, use the following command line:
sh Configure -Duserelocatableinc
Then the paths in @INC (and everything else in %Config) can be
optionally located via the path of the perl executable.
That means that, if the string ".../" is found at the start of any
path, it's substituted with the directory of $^X. So, the relocation
can be configured on a per-directory basis, although the default with
"-Duserelocatableinc" is that everything is relocated. The initial
install is done to the original configured prefix.
This option is not compatible with the building of a shared libperl
("-Duseshrplib"), because in that case perl is linked with an hard-coded
rpath that points at the libperl.so, that cannot be relocated.
=head2 Site-wide Policy settings
After Configure runs, it stores a number of common site-wide "policy"
answers (such as installation directories) 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's perl build
directory, and Configure will use it. This will work even if Policy.sh was
generated for another version of Perl, or on a system with a
different architecture and/or operating system. However, in such cases,
you should review the contents of the file before using it: for
example, your new target may not keep its man pages in the same place
as the system on which the file was generated.
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 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 as locations to search for modules by the perl
being built. The list of perl versions found will be put in the Configure
variable inc_version_list.
To disable this use of older perl modules, even completely valid pure perl
modules, you can specify to not include the paths found:
sh Configure -Dinc_version_list=none ...
When using the newer perl, you can add these paths again in the
$PERL5LIB environment variable or with perl's -I runtime option.
=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
make test
make install
as usual, and Perl will be built in /tmp/perl/build/directory.
=head2 Building a debugging perl
You can run perl scripts under the perl debugger at any time with
B<perl -d your_script>. If, however, you want to debug perl itself,
you probably want to have support for perl internal debugging code
(activated by adding -DDEBUGGING to ccflags), and/or support for the
system debugger by adding -g to the optimisation flags. For that,
use the parameter:
sh Configure -DDEBUGGING
or
sh Configure -DDEBUGGING=<mode>
For a more eye appealing call, -DEBUGGING is defined to be an alias
for -DDEBUGGING. For both, the -U calls are also supported, in order
to be able to overrule the hints or Policy.sh settings.
Here are the DEBUGGING modes:
=over 4
=item -DDEBUGGING
=item -DEBUGGING
=item -DEBUGGING=both
Sets both -DDEBUGGING in the ccflags, and adds -g to optimize.
You can actually specify -g and -DDEBUGGING independently (see below),
but usually it's convenient to have both.
=item -DEBUGGING=-g
=item -Doptimize=-g
Adds -g to optimize, but does not set -DDEBUGGING.
(Note: Your system may actually require something like cc -g2.
Check your man pages for cc(1) and also any hint file for your system.)
=item -DEBUGGING=none
=item -UDEBUGGING
Removes -g from optimize, and -DDEBUGGING from ccflags.
=back
If you are using a shared libperl, see the warnings about multiple
versions of perl under L<Building a shared Perl library>.
Note that a perl built with -DDEBUGGING will be bigger and will run more
slowly than a standard perl.
=head2 DTrace support
On platforms where DTrace is available, it may be enabled by
using the -Dusedtrace option to Configure. DTrace probes are available for
subroutine entry (sub-entry) and subroutine exit (sub-exit). Here's a
simple D script that uses them:
perl$target:::sub-entry, perl$target:::sub-return {
printf("%s %s (%s:%d)\n", probename == "sub-entry" ? "->" : "<-",
copyinstr(arg0), copyinstr(arg1), arg2);
}
=head2 Extensions
Perl ships with a number of standard extensions. These are contained
in the ext/ subdirectory.
By default, Configure will offer to build every extension which appears
to be supported. For example, Configure will offer to build GDBM_File
only if it is able to find the gdbm library.
To disable certain extensions so that they are not built, use the
-Dnoextensions=... and -Donlyextensions=... options. They both accept
a space-separated list of extensions, such as C<IPC/SysV>. The extensions
listed in
C<noextensions> are removed from the list of extensions to build, while
the C<onlyextensions> is rather more severe and builds only the listed
extensions. The latter should be used with extreme caution since
certain extensions are used by many other extensions and modules:
examples of such modules include Fcntl and IO. The order of processing
these options is first C<only> (if present), then C<no> (if present).
Of course, you may always run Configure interactively and select only
the extensions you want.
If you unpack any additional extensions in the ext/ directory before
running Configure, then Configure will offer to build those additional
extensions as well. Most users probably shouldn't have to do this --
it is usually easier to build additional extensions later after perl
has been installed. However, if you wish to have those additional
extensions statically linked into the perl binary, then this offers a
convenient way to do that in one step. (It is not necessary, however;
you can build and install extensions just fine even if you don't have
dynamic loading. See lib/ExtUtils/MakeMaker.pm for more details.)
Another way of specifying extra modules is described in
L<"Adding extra modules to the build"> below.
If you re-use an old config.sh but change your system (e.g. by
adding libgdbm) Configure will still offer your old choices of extensions
for the default answer, but it will also point out the discrepancy to
you.
=head2 Including locally-installed libraries
Perl comes with interfaces to number of libraries, including threads,
dbm, ndbm, gdbm, and Berkeley db. For the *db* extension, if
Configure can find the appropriate header files and libraries, it will
automatically include that extension. The threading extension needs
to be specified explicitely (see L<Threads>).
Those libraries are not distributed with perl. If your header (.h) files
for those libraries are not in a directory normally searched by your C
compiler, then you will need to include the appropriate -I/your/directory
option when prompted by Configure. If your libraries are not in a
directory normally searched by your C compiler and linker, then you will
need to include the appropriate -L/your/directory option when prompted
by Configure. See the examples below.
=head3 Examples
=over 4
=item gdbm in /usr/local
Suppose you have gdbm and want Configure to find it and build the
GDBM_File extension. This example assumes you have gdbm.h
installed in /usr/local/include/gdbm.h and libgdbm.a installed in
/usr/local/lib/libgdbm.a. Configure should figure all the
necessary steps out automatically.