- 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.