/repo: perl-5.22.2/INSTALL comparison

comparison perl-5.22.2/INSTALL @ 8045:a16537d2fe07

<xfix> tar xf perl-5.22.2.tar.gz # Ah, whatever, I\'m doing it anyway

author	HackBot
date	Sat, 14 May 2016 14:54:38 +0000
parents
children

comparison

equal deleted inserted replaced

-:711c038a7dce
+:a16537d2fe07
+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're building perl from a git repository, you should also consult
+the documentation in pod/perlgit.pod for information on that special
+circumstance.
+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 versions of Perl
+earlier than 5.22.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 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 the L<CPAN> module's
+C<autobundle> function 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).
+Note that the exact format and range of long doubles varies:
+the most common is the x86 80-bit (64 bits of mantissa) format,
+but there are others, with different mantissa and exponent ranges.
+=head3 "more bits"
+You can "Configure -Dusemorebits" to turn on both the 64-bit support
+and the long double support.
+=head3 quadmath
+One option for more precision is that gcc 4.6 and later have a library
+called quadmath, which implements the IEEE 754 quadruple precision
+(128-bit, 113 bits of mantissa) floating point numbers.  The library
+works at least on x86 and ia64 platforms.  It may be part of your gcc
+installation, or you may need to install it separately.
+With "Configure -Dusequadmath" you can try enabling its use, but note
+the compiler dependency, you may need to also add "-Dcc=...".
+At C level the type is called C<__float128> (note, not "long double"),
+but Perl source knows it as NV.  (This is not "long doubles".)
+=head3 Algorithmic Complexity Attacks on Hashes
+Perl 5.18 reworked the measures used to secure its hash function
+from algorithmic complexity attacks.  By default it will build with
+all of these measures enabled along with support for controlling and
+disabling them via environment variables.
+You can override various aspects of this feature by defining various
+symbols during configure. An example might be:
+Configure -Accflags=-DPERL_HASH_FUNC_SIPHASH
+B<Unless stated otherwise these options are considered experimental or
+insecure and are not recommended for production use.>
+Perl 5.18 includes support for multiple hash functions, and changed
+the default (to ONE_AT_A_TIME_HARD), you can choose a different
+algorithm by defining one of the following symbols. Note that as of
+Perl 5.18 we can only recommend use of the default or SIPHASH. All
+the others are known to have security issues and are for research
+purposes only.
+PERL_HASH_FUNC_SIPHASH
+PERL_HASH_FUNC_SDBM
+PERL_HASH_FUNC_DJB2
+PERL_HASH_FUNC_SUPERFAST
+PERL_HASH_FUNC_MURMUR3
+PERL_HASH_FUNC_ONE_AT_A_TIME
+PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
+PERL_HASH_FUNC_ONE_AT_A_TIME_OLD
+Perl 5.18 randomizes the order returned by keys(), values(), and each(),
+and allows controlling this behavior by using of the PERL_PERTURB_KEYS
+option. You can disable this option entirely with the define:
+PERL_PERTURB_KEYS_DISABLED
+You can disable the environment variable checks and specify the type of
+key traversal randomization to be used by defining one of these:
+PERL_PERTURB_KEYS_RANDOM
+PERL_PERTURB_KEYS_DETERMINISTIC
+In Perl 5.18 the seed used for the hash function is randomly selected
+at process start which can be overridden by specifying a seed by setting
+the PERL_HASH_SEED environment variable.
+You can change this behavior by building perl with the
+USE_HASH_SEED_EXPLICIT
+define, in which case one has to explicitly set the PERL_HASH_SEED
+environment variable to enable the security feature or by adding
+NO_HASH_SEED
+to the compilation flags to completely disable the randomisation feature.
+Note these modes are poorly tested, insecure and not recommended.
+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.
+See L<perlrun/PERL_HASH_SEED> and L<perlrun/PERL_PERTURB_KEYS> for
+details on the environment variables, and L<perlsec/Algorithmic
+Complexity Attacks> for further security details.
+=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
+Darwin, 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:
+./perl -MTestInit t/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.22.2.
+$version is the full perl version number, including subversion, e.g.
+5.12.3, 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        Default
+variable          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          Default
+variable            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 ...
+If you do want to use modules from some previous perl versions, the
+variable must contain a space separated list of directories under the
+site_perl directory, and has to include architecture-dependent
+directories separately, eg.
+sh Configure -Dinc_version_list="5.16.0/x86_64-linux 5.16.0" ...
+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 much bigger and will run
+much, much 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 explicitly (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.
+Specifically, when Configure prompts you for flags for
+your C compiler, you should include -I/usr/local/include, if it's
+not here yet. Similarly, when Configure prompts you for linker flags,
+you should include -L/usr/local/lib.
+If you are using dynamic loading, then when Configure prompts you for
+linker flags for dynamic loading, you should again include
+-L/usr/local/lib.
+Again, this should all happen automatically.  This should also work if
+you have gdbm installed in any of (/usr/local, /opt/local, /usr/gnu,
+/opt/gnu, /usr/GNU, or /opt/GNU).
+=item BerkeleyDB in /usr/local/BerkeleyDB
+The version of BerkeleyDB distributed by Oracle installs in a
+version-specific directory by default, typically something like
+/usr/local/BerkeleyDB.4.7.  To have Configure find that, you need to add
+-I/usr/local/BerkeleyDB.4.7/include to cc flags, as in the previous
+example, and you will also have to take extra steps to help Configure
+find -ldb.  Specifically, when Configure prompts you for library
+directories, add /usr/local/BerkeleyDB.4.7/lib to the list.  Also, you
+will need to add appropriate linker flags to tell the runtime linker
+where to find the BerkeleyDB shared libraries.
+It is possible to specify this from the command line (all on one
+line):
+sh Configure -de \
+-Dlocincpth='/usr/local/BerkeleyDB.4.7/include             \
+/usr/local/include' \
+-Dloclibpth='/usr/local/BerkeleyDB.4.7/lib /usr/local/lib' \
+-Aldflags='-R/usr/local/BerkeleyDB.4.7/lib'
+locincpth is a space-separated list of include directories to search.
+Configure will automatically add the appropriate -I directives.
+loclibpth is a space-separated list of library directories to search.
+Configure will automatically add the appropriate -L directives.
+The addition to ldflags is so that the dynamic linker knows where to find
+the BerkeleyDB libraries.  For Linux and Solaris, the -R option does that.
+Other systems may use different flags.  Use the appropriate flag for your
+system.
+=back
+=head2 Specifying a logical root directory
+If you are cross-compiling, or are using a compiler which has it's own
+headers and libraries in a nonstandard location, and your compiler
+understands the C<--sysroot> option, you can use the C<-Dsysroot> option
+to specify the logical root directory under which all libraries and
+headers are searched for. This patch adjusts Configure to search under
+$sysroot, instead of /.
+--sysroot is added to ccflags and friends so that make in
+ExtUtils::MakeMaker, and other extensions, will use it.
+=head2 Overriding an old config.sh
+If you want to use an old config.sh produced by a previous run of
+Configure, but override some of the items with command line options, you
+need to use B<Configure -O>.
+=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".)
+=head2 Malloc Issues
+Perl relies heavily on malloc(3) to grow data structures as needed,
+so perl's performance can be noticeably affected by the performance of
+the malloc function on your system.  The perl source is shipped with a
+version of malloc that has been optimized for the typical requests from
+perl, so there's a chance that it may be both faster and use less memory
+than your system malloc.
+However, if your system already has an excellent malloc, or if you are
+experiencing difficulties with extensions that use third-party libraries
+that call malloc, then you should probably use your system's malloc.
+(Or, you might wish to explore the malloc flags discussed below.)
+=over 4
+=item Using the system malloc
+To build without perl's malloc, you can use the Configure command
+	sh Configure -Uusemymalloc
+or you can answer 'n' at the appropriate interactive Configure prompt.
+Note that Perl's malloc isn't always used by default; that actually
+depends on your system. For example, on Linux and FreeBSD (and many more
+systems), Configure chooses to use the system's malloc by default.
+See the appropriate file in the F<hints/> directory to see how the
+default is set.
+=item -DPERL_POLLUTE_MALLOC
+NOTE: This flag is enabled automatically on some platforms if you just
+run Configure to accept all the defaults.
+Perl's malloc family of functions are normally called Perl_malloc(),
+Perl_realloc(), Perl_calloc() and Perl_mfree().
+These names do not clash with the system versions of these functions.
+If this flag is enabled, however, Perl's malloc family of functions
+will have the same names as the system versions.  This may be required
+sometimes if you have libraries that like to free() data that may have
+been allocated by Perl_malloc() and vice versa.
+Note that enabling this option may sometimes lead to duplicate symbols
+from the linker for malloc et al.  In such cases, the system probably
+does not allow its malloc functions to be fully replaced with custom
+versions.
+=item -DPERL_DEBUGGING_MSTATS
+This flag enables debugging mstats, which is required to use the
+Devel::Peek::mstat() function. You cannot enable this unless you are
+using Perl's malloc, so a typical Configure command would be
+sh Configure -Accflags=-DPERL_DEBUGGING_MSTATS -Dusemymalloc
+to enable this option.
+=back
+=head2 What if it doesn't work?
+If you run into problems, try some of the following ideas.
+If none of them help, then see L<"Reporting Problems"> below.
+=over 4
+=item Running Configure Interactively
+If Configure runs into trouble, remember that you can always run
+Configure interactively so that you can check (and correct) its
+guesses.
+All the installation questions have been moved to the top, so you don't
+have to wait for them.  Once you've handled them (and your C compiler and
+flags) you can type  &-d  at the next Configure prompt and Configure
+will use the defaults from then on.
+If you find yourself trying obscure command line incantations and
+config.over tricks, I recommend you run Configure interactively
+instead.  You'll probably save yourself time in the long run.
+=item Hint files
+Hint files tell Configure about a number of things:
+=over 4
+=item o
+The peculiarities or conventions of particular platforms -- non-standard
+library locations and names, default installation locations for binaries,
+and so on.
+=item o
+The deficiencies of the platform -- for example, library functions that,
+although present, are too badly broken to be usable; or limits on
+resources that are generously available on most platforms.
+=item o
+How best to optimize for the platform, both in terms of binary size
+and/or speed, and for Perl feature support. Because of wide variations in
+the implementation of shared libraries and of threading, for example,
+Configure often needs hints in order to be able to use these features.
+=back
+The perl distribution includes many system-specific hints files
+in the hints/ directory. If one of them matches your system, Configure
+will offer to use that hint file. Unless you have a very good reason
+not to, you should accept its offer.
+Several of the hint files contain additional important information.
+If you have any problems, it is a good idea to read the relevant hint
+file for further information.  See hints/solaris_2.sh for an extensive
+example.  More information about writing good hints is in the
+hints/README.hints file, which also explains hint files known as
+callback-units.
+Note that any hint file is read before any Policy file, meaning that
+Policy overrides hints -- see L</Site-wide Policy settings>.
+=item WHOA THERE!!!
+If you are re-using an old config.sh, it's possible that Configure
+detects different values from the ones specified in this file.  You will
+almost always want to keep the previous value, unless you have changed
+something on your system.
+For example, suppose you have added libgdbm.a to your system
+and you decide to reconfigure perl to use GDBM_File.  When you run
+Configure again, you will need to add -lgdbm to the list of libraries.
+Now, Configure will find your gdbm include file and library and will
+issue a message:
+*** WHOA THERE!!! ***
+	The previous value for $i_gdbm on this machine was "undef"!
+	Keep the previous value? [y]
+In this case, you do not want to keep the previous value, so you
+should answer 'n'.  (You'll also have to manually add GDBM_File to
+the list of dynamic extensions to build.)
+=item Changing Compilers
+If you change compilers or make other significant changes, you should
+probably not re-use your old config.sh.  Simply remove it or
+rename it, then rerun Configure with the options you want to use.
+=item Propagating your changes to config.sh
+If you make any changes to config.sh, you should propagate
+them to all the .SH files by running
+	sh Configure -S
+You will then have to rebuild by running
+	make depend
+	make
+=item config.over and config.arch
+You can also supply a shell script config.over to override
+Configure's guesses.  It will get loaded up at the very end, just
+before config.sh is created.  You have to be careful with this,
+however, as Configure does no checking that your changes make sense.
+This file is usually good for site-specific customizations.
+There is also another file that, if it exists, is loaded before the
+config.over, called config.arch.  This file is intended to be per
+architecture, not per site, and usually it's the architecture-specific
+hints file that creates the config.arch.
+=item config.h
+Many of the system dependencies are contained in config.h.
+Configure builds config.h by running the config_h.SH script.
+The values for the variables are taken from config.sh.
+If there are any problems, you can edit config.h directly.  Beware,
+though, that the next time you run Configure, your changes will be
+lost.
+=item cflags
+If you have any additional changes to make to the C compiler command
+line, they can be made in cflags.SH.  For instance, to turn off the
+optimizer on toke.c, find the switch structure marked 'or customize here',
+and add a line for toke.c ahead of the catch-all *) so that it now reads:
+: or customize here
+case "$file" in
+toke) optimize='-g' ;;
+*) ;;
+You should not edit the generated file cflags directly, as your changes
+will be lost the next time you run Configure, or if you edit config.sh.
+To explore various ways of changing ccflags from within a hint file,
+see the file hints/README.hints.
+To change the C flags for all the files, edit config.sh and change either
+$ccflags or $optimize, and then re-run
+	sh Configure -S
+	make depend
+=item No sh
+If you don't have sh, you'll have to copy the sample file
+Porting/config.sh to config.sh and edit your config.sh to reflect your
+system's peculiarities.  See Porting/pumpkin.pod for more information.
+You'll probably also have to extensively modify the extension building
+mechanism.
+=item Porting information
+Specific information for the OS/2, Plan 9, VMS and Win32 ports is in the
+corresponding README files and subdirectories.  Additional information,
+including a glossary of all those config.sh variables, is in the Porting
+subdirectory.  Porting/Glossary should especially come in handy.
+Ports for other systems may also be available.  You should check out
+http://www.cpan.org/ports for current information on ports to
+various other operating systems.
+If you plan to port Perl to a new architecture, study carefully the
+section titled "Philosophical Issues in Patching and Porting Perl"
+in the file Porting/pumpkin.pod and the file pod/perlgit.pod.
+Study also how other non-UNIX ports have solved problems.
+=back
+=head2 Adding extra modules to the build
+You can specify extra modules or module bundles to be fetched from the
+CPAN and installed as part of the Perl build.  Either use the -Dextras=...
+command line parameter to Configure, for example like this:
+	Configure -Dextras="Bundle::LWP DBI"
+or answer first 'y' to the question 'Install any extra modules?' and
+then answer "Bundle::LWP DBI" to the 'Extras?' question.
+The module or the bundle names are as for the CPAN module 'install'
+command.  This will only work if those modules are to be built as dynamic
+extensions.  If you wish to include those extra modules as static
+extensions, see L<"Extensions"> above.
+Notice that because the CPAN module will be used to fetch the extra
+modules, you will need access to the CPAN, either via the Internet,
+or via a local copy such as a CD-ROM or a local CPAN mirror.  If you
+do not, using the extra modules option will die horribly.
+Also notice that you yourself are responsible for satisfying any extra
+dependencies such as external headers or libraries BEFORE trying the
+build.  For example: you will need to have the Foo database specific
+headers and libraries installed for the DBD::Foo module.  The Configure
+process or the Perl build process will not help you with these.
+=head2 suidperl
+suidperl was an optional component of earlier releases of perl. It is no
+longer available.  Instead, use a tool specifically designed to handle
+changes in privileges, such as B<sudo>.
+=head1 make depend
+This will look for all the includes.  The output is stored in makefile.
+The only difference between Makefile and makefile is the dependencies at
+the bottom of makefile.  If you have to make any changes, you should edit
+makefile, not Makefile, since the Unix make command reads makefile first.
+(On non-Unix systems, the output may be stored in a different file.
+Check the value of $firstmakefile in your config.sh if in doubt.)
+Configure will offer to do this step for you, so it isn't listed
+explicitly above.
+=head1 make
+This will attempt to make perl in the current directory.
+=head2 Expected errors
+These error reports are normal, and can be ignored:
+...
+make: [extra.pods] Error 1 (ignored)
+...
+make: [extras.make] Error 1 (ignored)
+=head2 What if it doesn't work?
+If you can't compile successfully, try some of the following ideas.
+If none of them help, and careful reading of the error message and
+the relevant manual pages on your system doesn't help,
+then see L<"Reporting Problems"> below.
+=over 4
+=item hints
+If you used a hint file, try reading the comments in the hint file
+for further tips and information.
+=item extensions
+If you can successfully build miniperl, but the process crashes
+during the building of extensions, run
+	make minitest
+to test your version of miniperl.
+=item locale
+If you have any locale-related environment variables set, try unsetting
+them.  I have some reports that some versions of IRIX hang while
+running B<./miniperl configpm> with locales other than the C locale.
+See the discussion under L<"make test"> below about locales and the
+whole L<perllocale/"LOCALE PROBLEMS"> section in the file
+pod/perllocale.pod.  The latter is especially useful if you see something
+like this
+	perl: warning: Setting locale failed.
+	perl: warning: Please check that your locale settings:
+	        LC_ALL = "En_US",
+	        LANG = (unset)
+	    are supported and installed on your system.
+	perl: warning: Falling back to the standard locale ("C").
+at Perl startup.
+=item other environment variables
+Configure does not check for environment variables that can sometimes
+have a major influence on how perl is built or tested. For example,
+OBJECT_MODE on AIX determines the way the compiler and linker deal with
+their objects, but this is a variable that only influences build-time
+behaviour, and should not affect the perl scripts that are eventually
+executed by the perl binary. Other variables, like PERL_UNICODE,
+PERL5LIB, and PERL5OPT will influence the behaviour of the test suite.
+So if you are getting strange test failures, you may want to try
+retesting with the various PERL variables unset.
+=item varargs
+If you get varargs problems with gcc, be sure that gcc is installed
+correctly and that you are not passing -I/usr/include to gcc.  When using
+gcc, you should probably have i_stdarg='define' and i_varargs='undef'
+in config.sh.  The problem is usually solved by installing gcc
+correctly.  If you do change config.sh, don't forget to propagate
+your changes (see L<"Propagating your changes to config.sh"> below).
+See also the L<"vsprintf"> item below.
+=item util.c
+If you get error messages such as the following (the exact line
+numbers and function name may vary in different versions of perl):
+util.c: In function 'Perl_form':
+util.c:1107: number of arguments doesn't match prototype
+proto.h:125: prototype declaration
+it might well be a symptom of the gcc "varargs problem".  See the
+previous L<"varargs"> item.
+=item LD_LIBRARY_PATH
+If you run into dynamic loading problems, check your setting of
+the LD_LIBRARY_PATH environment variable.  If you're creating a static
+Perl library (libperl.a rather than libperl.so) it should build
+fine with LD_LIBRARY_PATH unset, though that may depend on details
+of your local setup.
+=item nm extraction
+If Configure seems to be having trouble finding library functions,
+try not using nm extraction.  You can do this from the command line
+with
+	sh Configure -Uusenm
+or by answering the nm extraction question interactively.
+If you have previously run Configure, you should not reuse your old
+config.sh.
+=item umask not found
+If the build processes encounters errors relating to umask(), the problem
+is probably that Configure couldn't find your umask() system call.
+Check your config.sh.  You should have d_umask='define'.  If you don't,
+this is probably the L<"nm extraction"> problem discussed above.  Also,
+try reading the hints file for your system for further information.
+=item vsprintf
+If you run into problems with vsprintf in compiling util.c, the
+problem is probably that Configure failed to detect your system's
+version of vsprintf().  Check whether your system has vprintf().
+(Virtually all modern Unix systems do.)  Then, check the variable
+d_vprintf in config.sh.  If your system has vprintf, it should be:
+	d_vprintf='define'
+If Configure guessed wrong, it is likely that Configure guessed wrong
+on a number of other common functions too.  This is probably
+the L<"nm extraction"> problem discussed above.
+=item do_aspawn
+If you run into problems relating to do_aspawn or do_spawn, the
+problem is probably that Configure failed to detect your system's
+fork() function.  Follow the procedure in the previous item
+on L<"nm extraction">.
+=item __inet_* errors
+If you receive unresolved symbol errors during Perl build and/or test
+referring to __inet_* symbols, check to see whether BIND 8.1 is
+installed.  It installs a /usr/local/include/arpa/inet.h that refers to
+these symbols.  Versions of BIND later than 8.1 do not install inet.h
+in that location and avoid the errors.  You should probably update to a
+newer version of BIND (and remove the files the old one left behind).
+If you can't, you can either link with the updated resolver library
+provided with BIND 8.1 or rename /usr/local/bin/arpa/inet.h during the
+Perl build and test process to avoid the problem.
+=item .*_r() prototype NOT found
+On a related note, if you see a bunch of complaints like the above about
+reentrant functions -- specifically networking-related ones -- being
+present but without prototypes available, check to see if BIND 8.1 (or
+possibly other BIND 8 versions) is (or has been) installed. They install
+header files such as netdb.h into places such as /usr/local/include (or
+into another directory as specified at build/install time), at least
+optionally.  Remove them or put them in someplace that isn't in the C
+preprocessor's header file include search path (determined by -I options
+plus defaults, normally /usr/include).
+=item #error "No DATAMODEL_NATIVE specified"
+This is a common error when trying to build perl on Solaris 2.6 with a
+gcc installation from Solaris 2.5 or 2.5.1.  The Solaris header files
+changed, so you need to update your gcc installation.  You can either
+rerun the fixincludes script from gcc or take the opportunity to
+update your gcc installation.
+=item Optimizer
+If you can't compile successfully, try turning off your compiler's
+optimizer.  Edit config.sh and change the line
+	optimize='-O'
+to
+	optimize=' '
+then propagate your changes with B<sh Configure -S> and rebuild
+with B<make depend; make>.
+=item Missing functions and Undefined symbols
+If the build of miniperl fails with a long list of missing functions or
+undefined symbols, check the libs variable in the config.sh file.  It
+should look something like
+	libs='-lsocket -lnsl -ldl -lm -lc'
+The exact libraries will vary from system to system, but you typically
+need to include at least the math library -lm.  Normally, Configure
+will suggest the correct defaults.  If the libs variable is empty, you
+need to start all over again.  Run
+	make distclean
+and start from the very beginning.  This time, unless you are sure of
+what you are doing, accept the default list of libraries suggested by
+Configure.
+If the libs variable is missing -lm, there is a chance that libm.so.1
+is available, but the required (symbolic) link to libm.so is missing.
+(same could be the case for other libraries like libcrypt.so).  You
+should check your installation for packages that create that link, and
+if no package is installed that supplies that link or you cannot install
+them, make the symbolic link yourself e.g.:
+$ rpm -qf /usr/lib64/libm.so
+glibc-devel-2.15-22.17.1.x86_64
+$ ls -lgo /usr/lib64/libm.so
+lrwxrwxrwx 1 16 Jan  7  2013 /usr/lib64/libm.so -> /lib64/libm.so.6
+or
+$ sudo ln -s /lib64/libm.so.6 /lib64/libm.so
+If the libs variable looks correct, you might have the
+L<"nm extraction"> problem discussed above.
+If you still have missing routines or undefined symbols, you probably
+need to add some library or other, make a symbolic link like described
+above, or you need to undefine some feature that Configure thought was
+there but is defective or incomplete.  If you used a hint file, see if
+it has any relevant advice.  You can also look through through config.h
+for likely suspects.
+=item toke.c
+Some compilers will not compile or optimize the larger files (such as
+toke.c) without some extra switches to use larger jump offsets or
+allocate larger internal tables.  You can customize the switches for
+each file in cflags.SH.  It's okay to insert rules for specific files
+into makefile since a default rule only takes effect in the absence of a
+specific rule.
+=item Missing dbmclose
+SCO prior to 3.2.4 may be missing dbmclose().  An upgrade to 3.2.4
+that includes libdbm.nfs (which includes dbmclose()) may be available.
+=item error: too few arguments to function 'dbmclose'
+Building ODBM_File on some (Open)SUSE distributions might run into this
+error, as the header file is broken. There are two ways to deal with this
+1. Disable the use of ODBM_FILE
+Configure ... -Dnoextensions=ODBM_File
+2. Fix the header file, somewhat like this:
+--- a/usr/include/dbm.h  2010-03-24 08:54:59.000000000 +0100
++++ b/usr/include/dbm.h  2010-03-24 08:55:15.000000000 +0100
+@@ -59,4 +59,4 @@ extern datum  firstkey __P((void));
+extern datum   nextkey __P((datum key));
+-extern int     dbmclose __P((DBM *));
++extern int     dbmclose __P((void));
+=item Warning (mostly harmless): No library found for -lsomething
+If you see such a message during the building of an extension, but
+the extension passes its tests anyway (see L<"make test"> below),
+then don't worry about the warning message.  The extension
+Makefile.PL goes looking for various libraries needed on various
+systems; few systems will need all the possible libraries listed.
+Most users will see warnings for the ones they don't have.  The
+phrase 'mostly harmless' is intended to reassure you that nothing
+unusual is happening, and the build process is continuing.
+On the other hand, if you are building GDBM_File and you get the
+message
+Warning (mostly harmless): No library found for -lgdbm
+then it's likely you're going to run into trouble somewhere along
+the line, since it's hard to see how you can use the GDBM_File
+extension without the -lgdbm library.
+It is true that, in principle, Configure could have figured all of
+this out, but Configure and the extension building process are not
+quite that tightly coordinated.
+=item sh: ar: not found
+This is a message from your shell telling you that the command 'ar'
+was not found.  You need to check your PATH environment variable to
+make sure that it includes the directory with the 'ar' command.  This
+is a common problem on Solaris, where 'ar' is in the /usr/ccs/bin
+directory.
+=item db-recno failure on tests 51, 53 and 55
+Old versions of the DB library (including the DB library which comes
+with FreeBSD 2.1) had broken handling of recno databases with modified
+bval settings.  Upgrade your DB library or OS.
+=item Bad arg length for semctl, is XX, should be ZZZ
+If you get this error message from the ext/IPC/SysV/t/sem test, your
+System V IPC may be broken.  The XX typically is 20, and that is what ZZZ
+also should be.  Consider upgrading your OS, or reconfiguring your OS
+to include the System V semaphores.
+=item ext/IPC/SysV/t/sem........semget: No space left on device
+Either your account or the whole system has run out of semaphores.  Or
+both.  Either list the semaphores with "ipcs" and remove the unneeded
+ones (which ones these are depends on your system and applications)
+with "ipcrm -s SEMAPHORE_ID_HERE" or configure more semaphores to your
+system.
+=item GNU binutils
+If you mix GNU binutils (nm, ld, ar) with equivalent vendor-supplied
+tools you may be in for some trouble.  For example creating archives
+with an old GNU 'ar' and then using a new current vendor-supplied 'ld'
+may lead into linking problems.  Either recompile your GNU binutils
+under your current operating system release, or modify your PATH not
+to include the GNU utils before running Configure, or specify the
+vendor-supplied utilities explicitly to Configure, for example by
+Configure -Dar=/bin/ar.
+=item THIS PACKAGE SEEMS TO BE INCOMPLETE
+The F<Configure> program has not been able to find all the files which
+make up the complete Perl distribution.  You may have a damaged source
+archive file (in which case you may also have seen messages such as
+C<gzip: stdin: unexpected end of file> and C<tar: Unexpected EOF on
+archive file>), or you may have obtained a structurally-sound but
+incomplete archive.  In either case, try downloading again from the
+official site named at the start of this document.  If you do find
+that any site is carrying a corrupted or incomplete source code
+archive, please report it to the site's maintainer.
+=item invalid token: ##
+You are using a non-ANSI-compliant C compiler.  To compile Perl, you
+need to use a compiler that supports ANSI C.  If there is a README
+file for your system, it may have further details on your compiler
+options.
+=item Miscellaneous
+Some additional things that have been reported:
+Genix may need to use libc rather than libc_s, or #undef VARARGS.
+NCR Tower 32 (OS 2.01.01) may need -W2,-Sl,2000 and #undef MKDIR.
+UTS may need one or more of -K or -g, and #undef LSTAT.
+FreeBSD can fail the ext/IPC/SysV/t/sem.t test if SysV IPC has not been
+configured in the kernel.  Perl tries to detect this, though, and
+you will get a message telling you what to do.
+Building Perl on a system that has also BIND (headers and libraries)
+installed may run into troubles because BIND installs its own netdb.h
+and socket.h, which may not agree with the operating system's ideas of
+the same files.  Similarly, including -lbind may conflict with libc's
+view of the world.  You may have to tweak -Dlocincpth and -Dloclibpth
+to avoid the BIND.
+=back
+=head2 Cross-compilation
+Perl can be cross-compiled.  It is just not trivial, cross-compilation
+rarely is.  Perl is routinely cross-compiled for several platforms: as of
+January 2014, these include Android, Blackberry 10, PocketPC aka
+WinCE, ARM Linux, and Solaris.  Previous versions of
+Perl also provided support for Open Zaurus, Symbian, and
+the IBM OS/400, but it's unknown if those ports are still functional.
+These platforms are known as the B<target> platforms, while the systems
+where the compilation takes place are the B<host> platforms.
+What makes the situation difficult is that first of all,
+cross-compilation environments vary significantly in how they are set
+up and used, and secondly because the primary way of configuring Perl
+(using the rather large Unix-tool-dependent Configure script) is not
+awfully well suited for cross-compilation.  However, starting from
+version 5.18.0, the Configure script also knows two ways of supporting
+cross-compilation, so please keep reading.
+See the following files for more information about compiling Perl for
+the particular platforms:
+=over 4
+=item WinCE/PocketPC
+L<README.ce or perlce|perlce>
+=item Android
+L<"Cross-compilation" in README.android or
+perlandroid|perlandroid/Cross-compilation>
+=item Blackberry
+L<"Cross-compilation" in README.qnx or perlqnx|perlqnx/Cross-compilation>
+=item Solaris
+L<"CROSS-COMPILATION" in README.solaris or
+perlsolaris|perlsolaris/CROSS-COMPILATION>
+=item Linux
+This document; See below.
+=back
+Packaging and transferring either the core Perl modules or CPAN
+modules to the target platform is also left up to the each
+cross-compilation environment.  Often the cross-compilation target
+platforms are somewhat limited in diskspace: see the section
+L<Minimizing the Perl installation> to learn more of the minimal set
+of files required for a functional Perl installation.
+For some cross-compilation environments the Configure option
+C<-Dinstallprefix=...> might be handy, see L<Changing the installation
+directory>.
+About the cross-compilation support of Configure: There's two forms.
+The more common one requires some way of transferring and running
+executables in the target system, such as an ssh connection; this is the
+C<./Configure -Dusecrosscompile -Dtargethost=...> route.  The second
+method doesn't need access to the target system, but requires you to
+provide a config.sh, and and a canned Makefile; the rest of this section
+describes the former.
+This cross-compilation setup of Configure has successfully been used in
+a wide variety of setups, such as a 64-bit OS X host for an Android ARM
+target, or an amd64 Linux host targeting x86 Solaris, or even Windows.
+To run Configure in cross-compilation mode the basic switch that
+has to be used is C<-Dusecrosscompile>:
+sh ./Configure -des -Dusecrosscompile -D...
+This will make the cpp symbol USE_CROSS_COMPILE and the %Config
+symbol C<usecrosscompile> available.
+During the Configure and build, certain helper scripts will be created
+into the Cross/ subdirectory.  The scripts are used to execute a
+cross-compiled executable, and to transfer files to and from the
+target host.  The execution scripts are named F<run-*> and the
+transfer scripts F<to-*> and F<from-*>.  The part after the dash is
+the method to use for remote execution and transfer: by default the
+methods are B<ssh> and B<scp>, thus making the scripts F<run-ssh>,
+F<to-scp>, and F<from-scp>.
+To configure the scripts for a target host and a directory (in which
+the execution will happen and which is to and from where the transfer
+happens), supply Configure with
+-Dtargethost=so.me.ho.st -Dtargetdir=/tar/get/dir
+The targethost is what e.g. ssh will use as the hostname, the targetdir
+must exist (the scripts won't create it), the targetdir defaults to /tmp.
+You can also specify a username to use for ssh/rsh logins
+-Dtargetuser=luser
+but in case you don't, "root" will be used.  Similarly, you can specify
+a non-standard (i.e. not 22) port for the connection, if applicable,
+through
+-Dtargetport=2222
+If the name of C<cc> has the usual GNU C semantics for cross
+compilers, that is, CPU-OS-gcc, the target architecture (C<targetarch>),
+plus names of the C<ar>, C<nm>, and C<ranlib> will also be automatically
+chosen to be CPU-OS-ar and so on.
+(The C<ld> requires more thought and will be chosen later by Configure
+as appropriate).  This will also aid in guessing the proper
+operating system name for the target, which has other repercussions, like
+better defaults and possibly critical fixes for the platform.  If
+Configure isn't guessing the OS name properly, you may need to either add
+a hint file redirecting Configure's guess, or modify Configure to make
+the correct choice.
+If your compiler doesn't follow that convention, you will also need to
+specify which target environment to use, as well as C<ar> and friends:
+-Dtargetarch=arm-linux
+-Dcc=mycrossgcc
+-Dar=...
+Additionally, a cross-compilation toolchain will usually install it's own
+logical system root somewhere -- that is, it'll create a directory
+somewhere which includes subdirectories like 'include' or 'lib'.  For
+example, you may end up with C</skiff/local/arm-linux>, where
+C</skiff/local/arm-linux/bin> holds the binaries for cross-compilation,
+C</skiff/local/arm-linux/include> has the headers, and
+C</skiff/local/arm-linux/lib> has the library files.
+If this is the case, and you are using a compiler that understands
+C<--sysroot>, like gcc or clang, you'll want to specify the
+C<-Dsysroot> option for Configure:
+-Dsysroot=/skiff/local/arm-linux
+However, if your don't have a suitable directory to pass to C<-Dsysroot>,
+you will also need to specify which target environment to use:
+-Dusrinc=/skiff/local/arm-linux/include
+-Dincpth=/skiff/local/arm-linux/include
+-Dlibpth=/skiff/local/arm-linux/lib
+In addition to the default execution/transfer methods you can also
+choose B<rsh> for execution, and B<rcp> or B<cp> for transfer,
+for example:
+-Dtargetrun=rsh -Dtargetto=rcp -Dtargetfrom=cp
+Putting it all together:
+sh ./Configure -des -Dusecrosscompile \
+-Dtargethost=so.me.ho.st \
+-Dtargetdir=/tar/get/dir \
+-Dtargetuser=root \
+-Dtargetarch=arm-linux \
+-Dcc=arm-linux-gcc \
+-Dsysroot=/skiff/local/arm-linux \
+-D...
+or if you are happy with the defaults:
+sh ./Configure -des -Dusecrosscompile \
+-Dtargethost=so.me.ho.st \
+-Dcc=arm-linux-gcc \
+-D...
+Another example where the cross-compiler has been installed under
+F</usr/local/arm/2.95.5>:
+sh ./Configure -des -Dusecrosscompile \
+-Dtargethost=so.me.ho.st \
+-Dcc=/usr/local/arm/2.95.5/bin/arm-linux-gcc \
+-Dsysroot=/usr/local/arm/2.95.5
+There is also a C<targetenv> option for Configure which can be used
+to modify the environment of the target just before testing begins
+during 'make test'.  For example, if the target system has a nonstandard
+/tmp location, you could do this:
+-Dtargetenv="export TMPDIR=/other/tmp;"
+If you are planning on cross-compiling to several platforms, or some
+other thing that would involve running Configure several times, there are
+two options that can be used to speed things up considerably.
+As a bit of background, when you
+call Configure with C<-Dusecrosscompile>, it begins by actually partially
+building a miniperl on the host machine, as well as the generate_uudmap
+binary, and we end up using that during the build.
+So instead of building that new perl every single time, you can build it
+just once in a separate directory, and then pass the resulting binaries
+to Configure like this:
+-Dhostperl=/path/to/second/build/dir/miniperl
+-Dhostgenerate=/path/to/second/build/dir/generate_uudmap
+Much less commonly, if you are cross-compiling from an ASCII host to an
+EBCDIC target, or vise versa, you'll have to pass C<-Uhostgenerate> to
+Configure, to signify that you want to build a generate_uudmap binary
+that, during make, will be run on the target system.
+=head1 make test
+This will run the regression tests on the perl you just made.  If
+'make test' doesn't say "All tests successful" then something went
+wrong.
+Note that you can't run the tests in background if this disables
+opening of /dev/tty. You can use 'make test-notty' in that case but
+a few tty tests will be skipped.
+=head2 What if make test doesn't work?
+If make test bombs out, just cd to the t directory and run ./TEST
+by hand to see if it makes any difference.
+One way to get more detailed information about failed tests and
+individual subtests is to run the harness from the t directory:
+	cd t ; ./perl harness <list of tests>
+(this assumes that most basic tests succeed, since harness uses
+complicated constructs). If no list of tests is provided, harness
+will run all tests.
+If individual tests fail, you can often run them by hand (from the main
+perl directory), e.g.,
+	./perl -MTestInit t/op/groups.t
+You should also read the individual tests to see if there are any helpful
+comments that apply to your system.  You may also need to setup your
+shared library path if you get errors like:
+	/sbin/loader: Fatal Error: cannot map libperl.so
+The file t/README in the t subdirectory contains more information about
+running and modifying tests.
+See L</"Building a shared Perl library"> earlier in this document.
+=over 4
+=item locale
+Note:  One possible reason for errors is that some external programs
+may be broken due to the combination of your environment and the way
+'make test' exercises them.  For example, this may happen if you have
+one or more of these environment variables set:  LC_ALL LC_CTYPE
+LC_COLLATE LANG.  In some versions of UNIX, the non-English locales
+are known to cause programs to exhibit mysterious errors.
+If you have any of the above environment variables set, please try
+	setenv LC_ALL C
+(for C shell) or
+	LC_ALL=C;export LC_ALL
+for Bourne or Korn shell) from the command line and then retry
+make test.  If the tests then succeed, you may have a broken program that
+is confusing the testing.  Please run the troublesome test by hand as
+shown above and see whether you can locate the program.  Look for
+things like:  exec, `backquoted command`, system, open("|...") or
+open("...|").  All these mean that Perl is trying to run some
+external program.
+=item Timing problems
+Several tests in the test suite check timing functions, such as
+sleep(), and see if they return in a reasonable amount of time.
+If your system is quite busy and doesn't respond quickly enough,
+these tests might fail.  If possible, try running the tests again
+with the system under a lighter load.  These timing-sensitive
+and load-sensitive tests include F<t/op/alarm.t>,
+F<ext/Time-HiRes/t/HiRes.t>, F<ext/threads-shared/t/waithires.t>,
+F<ext/threads-shared/t/stress.t>, F<lib/Benchmark.t>,
+F<lib/Memoize/t/expmod_t.t>, and F<lib/Memoize/t/speed.t>.
+You might also experience some failures in F<t/op/stat.t> if you build
+perl on an NFS filesystem, if the remote clock and the system clock are
+different.
+=item Out of memory
+On some systems, particularly those with smaller amounts of RAM, some
+of the tests in t/op/pat.t may fail with an "Out of memory" message.
+For example, on my SparcStation IPC with 12 MB of RAM, in perl5.5.670,
+test 85 will fail if run under either t/TEST or t/harness.
+Try stopping other jobs on the system and then running the test by itself:
+	./perl -MTestInit t/op/pat.t
+to see if you have any better luck.  If your perl still fails this
+test, it does not necessarily mean you have a broken perl.  This test
+tries to exercise the regular expression subsystem quite thoroughly,
+and may well be far more demanding than your normal usage.
+=item libgcc_s.so.1: cannot open shared object file
+This message has been reported on gcc-3.2.3 and earlier installed with
+a non-standard prefix.  Setting the LD_LIBRARY_PATH environment variable
+(or equivalent) to include gcc's lib/ directory with the libgcc_s.so.1
+shared library should fix the problem.
+=item Failures from lib/File/Temp/t/security saying "system possibly insecure"
+First, such warnings are not necessarily serious or indicative of a
+real security threat.  That being said, they bear investigating.
+Note that each of the tests is run twice.  The first time is in the
+directory returned by File::Spec->tmpdir() (often /tmp on Unix
+systems), and the second time in the directory from which the test was
+run (usually the 't' directory, if the test was run as part of 'make
+test').
+The tests may fail for the following reasons:
+(1) If the directory the tests are being run in is owned by somebody
+other than the user running the tests, or by root (uid 0).
+This failure can happen if the Perl source code distribution is
+unpacked in such a way that the user IDs in the distribution package
+are used as-is.  Some tar programs do this.
+(2) If the directory the tests are being run in is writable by group or
+by others, and there is no sticky bit set for the directory.  (With
+UNIX/POSIX semantics, write access to a directory means the right to
+add or remove files in that directory.  The 'sticky bit' is a feature
+used in some UNIXes to give extra protection to files: if the bit is
+set for a directory, no one but the owner (or root) can remove that
+file even if the permissions would otherwise allow file removal by
+others.)
+This failure may or may not be a real problem: it depends on the
+permissions policy used on this particular system.  This failure can
+also happen if the system either doesn't support the sticky bit (this
+is the case with many non-UNIX platforms: in principle File::Temp
+should know about these platforms and skip the tests), or if the system
+supports the sticky bit but for some reason or reasons it is not being
+used.  This is, for example, the case with HP-UX: as of HP-UX release
+11.00, the sticky bit is very much supported, but HP-UX doesn't use it
+on its /tmp directory as shipped.  Also, as with the permissions, some
+local policy might dictate that the stickiness is not used.
+(3) If the system supports the POSIX 'chown giveaway' feature and if
+any of the parent directories of the temporary file back to the root
+directory are 'unsafe', using the definitions given above in (1) and
+(2).  For Unix systems, this is usually not an issue if you are
+building on a local disk.  See the documentation for the File::Temp
+module for more information about 'chown giveaway'.
+See the documentation for the File::Temp module for more information
+about the various security aspects of temporary files.
+=back
+The core distribution can now run its regression tests in parallel on
+Unix-like platforms. Instead of running C<make test>, set C<TEST_JOBS>
+in your environment to the number of tests to run in parallel, and run
+C<make test_harness>. On a Bourne-like shell, this can be done as
+TEST_JOBS=3 make test_harness  # Run 3 tests in parallel
+An environment variable is used, rather than parallel make itself,
+because L<TAP::Harness> needs to be able to schedule individual
+non-conflicting test scripts itself, and there is no standard interface
+to C<make> utilities to interact with their job schedulers.
+=head1 make install
+This will put perl into the public directory you specified to
+Configure; by default this is /usr/local/bin.  It will also try to put
+the man pages in a reasonable place.  It will not nroff the man pages,
+however.  You may need to be root to run B<make install>.  If you are not
+root, you must still have permission to install into the directories
+in question and you should ignore any messages about chown not working.
+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.)
+=head2 Installing perl under different names
+If you want to install perl under a name other than "perl" (for example,
+when installing perl with special features enabled, such as debugging),
+indicate the alternate name on the "make install" line, such as:
+make install PERLNAME=myperl
+You can separately change the base used for versioned names (like
+"perl5.8.9") by setting PERLNAME_VERBASE, like
+make install PERLNAME=perl5 PERLNAME_VERBASE=perl
+This can be useful if you have to install perl as "perl5" (e.g. to avoid
+conflicts with an ancient version in /usr/bin supplied by your vendor).
+Without this the versioned binary would be called "perl55.8.8".
+=head2 Installing perl under a different directory
+You can install perl under a different destination directory by using
+the DESTDIR variable during C<make install>, with a command like
+	make install DESTDIR=/tmp/perl5
+DESTDIR is automatically prepended to all the installation paths.  See
+the example in L<"DESTDIR"> above.
+=head2 Installed files
+If you want to see exactly what will happen without installing
+anything, you can run
+	./perl installperl -n
+	./perl installman -n
+make install will install the following:
+binaries
+	perl,
+	    perl5.n.n	where 5.n.n is the current release number.  This
+			will be a link to perl.
+scripts
+	cppstdin	This is used by the deprecated switch perl -P,
+			if your cc -E can't read from stdin.
+	c2ph, pstruct	Scripts for handling C structures in header
+files.
+	corelist	Shows versions of modules that come with
+different
+			versions of perl.
+	cpan		The CPAN shell.
+	enc2xs		Encoding module generator.
+	h2ph		Extract constants and simple macros from C
+headers.
+	h2xs		Converts C .h header files to Perl extensions.
+	instmodsh	A shell to examine installed modules.
+	libnetcfg	Configure libnet.
+	perlbug		Tool to report bugs in Perl.
+	perldoc		Tool to read perl's pod documentation.
+	perlivp		Perl Installation Verification Procedure.
+	piconv		A Perl implementation of the encoding conversion
+			utility iconv.
+	pl2pm		Convert Perl 4 .pl files to Perl 5 .pm modules.
+	pod2html,	Converters from perl's pod documentation format
+	pod2man,
+	pod2text,
+	pod2usage
+	podchecker	POD syntax checker.
+	podselect	Prints sections of POD documentation.
+	prove		A command-line tool for running tests.
+	psed		A Perl implementation of sed.
+	ptar		A Perl implementation of tar.
+	ptardiff	A diff for tar archives.
+	ptargrep	A grep for tar archives.
+	shasum		A tool to print or check SHA checksums.
+	splain		Describe Perl warnings and errors.
+	xsubpp		Compiler to convert Perl XS code into C code.
+	zipdetails	display the internal structure of zip files
+library files
+			in $privlib and $archlib specified to
+			Configure, usually under /usr/local/lib/perl5/.
+documentation
+	man pages	in $man1dir, usually /usr/local/man/man1.
+	module man
+	pages		in $man3dir, usually /usr/local/man/man3.
+	pod/*.pod	in $privlib/pod/.
+installperl will also create the directories listed above
+in L<"Installation Directories">.
+Perl's *.h header files and the libperl library are also installed
+under $archlib so that any user may later build new modules, run the
+optional Perl compiler, or embed the perl interpreter into another
+program even if the Perl source is no longer available.
+=head2 Installing only version-specific parts
+Sometimes you only want to install the version-specific parts of the perl
+installation.  For example, you may wish to install a newer version of
+perl alongside an already installed production version without
+disabling installation of new modules for the production version.
+To only install the version-specific parts of the perl installation, run
+	Configure -Dversiononly
+or answer 'y' to the appropriate Configure prompt.  Alternatively,
+you can just manually run
+	./perl installperl -v
+and skip installman altogether.
+See also L<"Maintaining completely separate versions"> for another
+approach.
+=head1 cd /usr/include; h2ph *.h sys/*.h
+Some perl scripts need to be able to obtain information from the
+system header files.  This command will convert the most commonly used
+header files in /usr/include into files that can be easily interpreted
+by perl.  These files will be placed in the architecture-dependent
+library ($archlib) directory you specified to Configure.
+Note: Due to differences in the C and perl languages, the conversion
+of the header files is not perfect.  You will probably have to
+hand-edit some of the converted files to get them to parse correctly.
+For example, h2ph breaks spectacularly on type casting and certain
+structures.
+=head1 installhtml --help
+Some sites may wish to make perl documentation available in HTML
+format.  The installhtml utility can be used to convert pod
+documentation into linked HTML files and install them.
+Currently, the supplied ./installhtml script does not make use of the
+html Configure variables.  This should be fixed in a future release.
+The following command-line is an example of one used to convert
+perl documentation:
+./installhtml                   \
+--podroot=.                 \
+--podpath=lib:ext:pod:vms   \
+--recurse                   \
+--htmldir=/perl/nmanual     \
+--htmlroot=/perl/nmanual    \
+--splithead=pod/perlipc     \
+--splititem=pod/perlfunc    \
+--verbose
+See the documentation in installhtml for more details.  It can take
+many minutes to execute a large installation and you should expect to
+see warnings like "no title", "unexpected directive" and "cannot
+resolve" as the files are processed. We are aware of these problems
+(and would welcome patches for them).
+You may find it helpful to run installhtml twice. That should reduce
+the number of "cannot resolve" warnings.
+=head1 cd pod && make tex && (process the latex files)
+Some sites may also wish to make the documentation in the pod/ directory
+available in TeX format.  Type
+	(cd pod && make tex && <process the latex files>)
+=head1 Starting all over again
+If you wish to rebuild perl from the same build directory, you should
+clean it out 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.  (A plain 'make clean' is now
+eqivalent to 'make realclean'.)
+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 not reuse
+your old config.sh.
+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"> above.
+=head1 Reporting Problems
+Wherever possible please use the perlbug tool supplied with this Perl
+to report problems, as it automatically includes summary configuration
+information about your perl, which may help us track down problems far
+more quickly. But first you should read the advice in this file,
+carefully re-read the error message and check the relevant manual pages
+on your system, as these may help you find an immediate solution.  If
+you are not sure whether what you are seeing is a bug, you can send a
+message describing the problem to the comp.lang.perl.misc newsgroup to
+get advice.
+The perlbug tool is installed along with perl, so after you have
+completed C<make install> it should be possible to run it with plain
+C<perlbug>.  If the install fails, or you want to report problems with
+C<make test> without installing perl, then you can use C<make nok> to
+run perlbug to report the problem, or run it by hand from this source
+directory with C<./perl -Ilib utils/perlbug>
+If the build fails too early to run perlbug uninstalled, then please
+B<run> the C<./myconfig> shell script, and mail its output along with
+an accurate description of your problem to perlbug@perl.org
+If Configure itself fails, and does not generate a config.sh file
+(needed to run C<./myconfig>), then please mail perlbug@perl.org the
+description of how Configure fails along with details of your system
+-- for example the output from running C<uname -a>
+Please try to make your message brief but clear.  Brief, clear bug
+reports tend to get answered more quickly.  Please don't worry if your
+written English is not great -- what matters is how well you describe
+the important technical details of the problem you have encountered,
+not whether your grammar and spelling is flawless.
+Trim out unnecessary information.  Do not include large files (such as
+config.sh or a complete Configure or make log) unless absolutely
+necessary.  Do not include a complete transcript of your build
+session.  Just include the failing commands, the relevant error
+messages, and whatever preceding commands are necessary to give the
+appropriate context.  Plain text should usually be sufficient -- fancy
+attachments or encodings may actually reduce the number of people who
+read your message.  Your message will get relayed to over 400
+subscribers around the world so please try to keep it brief but clear.
+If the bug you are reporting has security implications, which make it
+inappropriate to send to a publicly archived mailing list, then please
+send it to perl5-security-report@perl.org. This points to a closed
+subscription unarchived mailing list, which includes all the core
+committers, who be able to help assess the impact of issues, figure out
+a resolution, and help co-ordinate the release of patches to mitigate or
+fix the problem across all platforms on which Perl is supported. Please
+only use this address for security issues in the Perl core, not for
+modules independently distributed on CPAN.
+If you are unsure what makes a good bug report please read "How to
+report Bugs Effectively" by Simon Tatham:
+http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
+=head1 Coexistence with earlier versions of perl 5
+Perl 5.22.2 is not binary compatible with versions of Perl earlier than
+5.22.0.
+In other words, you will have to recompile your XS modules.
+In general, you can usually safely upgrade from one version of Perl
+(e.g.  5.X.Y) to another similar minor version (e.g. 5.X.(Y+1))) without
+re-compiling all of your extensions.  You can also safely leave the old
+version around in case the new version causes you problems for some
+reason.
+Usually, most extensions will probably not need to be recompiled to be
+used with a newer version of Perl.  Here is how it is supposed to work.
+(These examples assume you accept all the Configure defaults.)
+Suppose you already have version 5.8.7 installed.  The directories
+searched by 5.8.7 are typically like:
+	/usr/local/lib/perl5/5.8.7/$archname
+	/usr/local/lib/perl5/5.8.7
+	/usr/local/lib/perl5/site_perl/5.8.7/$archname
+	/usr/local/lib/perl5/site_perl/5.8.7
+Now, suppose you install version 5.8.8.  The directories
+searched by version 5.8.8 will be:
+	/usr/local/lib/perl5/5.8.8/$archname
+	/usr/local/lib/perl5/5.8.8
+	/usr/local/lib/perl5/site_perl/5.8.8/$archname
+	/usr/local/lib/perl5/site_perl/5.8.8
+	/usr/local/lib/perl5/site_perl/5.8.7/$archname
+	/usr/local/lib/perl5/site_perl/5.8.7
+	/usr/local/lib/perl5/site_perl/
+Notice the last three entries -- Perl understands the default structure
+of the $sitelib directories and will look back in older, compatible
+directories.  This way, modules installed under 5.8.7 will continue
+to be usable by 5.8.7 but will also accessible to 5.8.8.  Further,
+suppose that you upgrade a module to one which requires features
+present only in 5.8.8.  That new module will get installed into
+/usr/local/lib/perl5/site_perl/5.8.8 and will be available to 5.8.8,
+but will not interfere with the 5.8.7 version.
+The last entry, /usr/local/lib/perl5/site_perl/, is there so that
+5.6.0 and above will look for 5.004-era pure perl modules.
+Lastly, suppose you now install 5.10.0, which is not binary compatible
+with 5.8.x.  The directories searched by 5.10.0 (if you don't change the
+Configure defaults) will be:
+	/usr/local/lib/perl5/5.10.0/$archname
+	/usr/local/lib/perl5/5.10.0
+	/usr/local/lib/perl5/site_perl/5.10.0/$archname
+	/usr/local/lib/perl5/site_perl/5.10.0
+	/usr/local/lib/perl5/site_perl/5.8.8
+	/usr/local/lib/perl5/site_perl/5.8.7
+	/usr/local/lib/perl5/site_perl/
+Note that the earlier $archname entries are now gone, but pure perl
+modules from earlier versions will still be found.
+This way, you can choose to share compatible extensions, but also upgrade
+to a newer version of an extension that may be incompatible with earlier
+versions, without breaking the earlier versions' installations.
+=head2 Maintaining completely separate versions
+Many users prefer to keep all versions of perl in completely
+separate directories.  This guarantees that an update to one version
+won't interfere with another version.  (The defaults guarantee this for
+libraries after 5.6.0, but not for executables. TODO?)  One convenient
+way to do this is by using a separate prefix for each version, such as
+	sh Configure -Dprefix=/opt/perl5.22.2
+and adding /opt/perl5.22.2/bin to the shell PATH variable.  Such users
+may also wish to add a symbolic link /usr/local/bin/perl so that
+scripts can still start with #!/usr/local/bin/perl.
+Others might share a common directory for maintenance sub-versions
+(e.g. 5.10 for all 5.10.x versions), but change directory with
+each major version.
+If you are installing a development subversion, you probably ought to
+seriously consider using a separate directory, since development
+subversions may not have all the compatibility wrinkles ironed out
+yet.
+=head2 Upgrading from 5.21.11 or earlier
+B<Perl 5.22.2 may not be binary compatible with Perl 5.21.11 or
+earlier Perl releases.>  Perl modules having binary parts
+(meaning that a C compiler is used) will have to be recompiled to be
+used with 5.22.2.  If you find you do need to rebuild an extension with
+5.22.2, you may safely do so without disturbing the older
+installations.  (See L<"Coexistence with earlier versions of perl 5">
+above.)
+See your installed copy of the perllocal.pod file for a (possibly
+incomplete) list of locally installed modules.  Note that you want
+perllocal.pod, not perllocale.pod, for installed module information.
+=head1 Minimizing the Perl installation
+The following section is meant for people worrying about squeezing the
+Perl installation into minimal systems (for example when installing
+operating systems, or in really small filesystems).
+Leaving out as many extensions as possible is an obvious way:
+Encode, with its big conversion tables, consumes a lot of
+space.  On the other hand, you cannot throw away everything.  The
+Fcntl module is pretty essential.  If you need to do network
+programming, you'll appreciate the Socket module, and so forth: it all
+depends on what do you need to do.
+In the following we offer two different slimmed down installation
+recipes.  They are informative, not normative: the choice of files
+depends on what you need.
+Firstly, the bare minimum to run this script
+use strict;
+use warnings;
+foreach my $f (</*>) {
+print("$f\n");
+}
+in Linux with perl-5.22.2 is as follows (under $Config{prefix}):
+./bin/perl
+./lib/perl5/5.22.2/strict.pm
+./lib/perl5/5.22.2/warnings.pm
+./lib/perl5/5.22.2/i686-linux/File/Glob.pm
+./lib/perl5/5.22.2/feature.pm
+./lib/perl5/5.22.2/XSLoader.pm
+./lib/perl5/5.22.2/i686-linux/auto/File/Glob/Glob.so
+Secondly, for perl-5.10.1, the Debian perl-base package contains 591
+files, (of which 510 are for lib/unicore) totaling about 3.5MB in its
+i386 version.  Omitting the lib/unicore/* files for brevity, the
+remaining files are:
+/usr/bin/perl
+/usr/bin/perl5.10.1
+/usr/lib/perl/5.10.1/Config.pm
+/usr/lib/perl/5.10.1/Config_git.pl
+/usr/lib/perl/5.10.1/Config_heavy.pl
+/usr/lib/perl/5.10.1/Cwd.pm
+/usr/lib/perl/5.10.1/DynaLoader.pm
+/usr/lib/perl/5.10.1/Errno.pm
+/usr/lib/perl/5.10.1/Fcntl.pm
+/usr/lib/perl/5.10.1/File/Glob.pm
+/usr/lib/perl/5.10.1/Hash/Util.pm
+/usr/lib/perl/5.10.1/IO.pm
+/usr/lib/perl/5.10.1/IO/File.pm
+/usr/lib/perl/5.10.1/IO/Handle.pm
+/usr/lib/perl/5.10.1/IO/Pipe.pm
+/usr/lib/perl/5.10.1/IO/Seekable.pm
+/usr/lib/perl/5.10.1/IO/Select.pm
+/usr/lib/perl/5.10.1/IO/Socket.pm
+/usr/lib/perl/5.10.1/IO/Socket/INET.pm
+/usr/lib/perl/5.10.1/IO/Socket/UNIX.pm
+/usr/lib/perl/5.10.1/List/Util.pm
+/usr/lib/perl/5.10.1/POSIX.pm
+/usr/lib/perl/5.10.1/Scalar/Util.pm
+/usr/lib/perl/5.10.1/Socket.pm
+/usr/lib/perl/5.10.1/XSLoader.pm
+/usr/lib/perl/5.10.1/auto/Cwd/Cwd.so
+/usr/lib/perl/5.10.1/auto/DynaLoader/autosplit.ix
+/usr/lib/perl/5.10.1/auto/DynaLoader/dl_expandspec.al
+/usr/lib/perl/5.10.1/auto/DynaLoader/dl_find_symbol_anywhere.al
+/usr/lib/perl/5.10.1/auto/DynaLoader/dl_findfile.al
+/usr/lib/perl/5.10.1/auto/Fcntl/Fcntl.so
+/usr/lib/perl/5.10.1/auto/File/Glob/Glob.so
+/usr/lib/perl/5.10.1/auto/Hash/Util/Util.so
+/usr/lib/perl/5.10.1/auto/IO/IO.so
+/usr/lib/perl/5.10.1/auto/List/Util/Util.so
+/usr/lib/perl/5.10.1/auto/POSIX/POSIX.so
+/usr/lib/perl/5.10.1/auto/POSIX/autosplit.ix
+/usr/lib/perl/5.10.1/auto/POSIX/load_imports.al
+/usr/lib/perl/5.10.1/auto/Socket/Socket.so
+/usr/lib/perl/5.10.1/lib.pm
+/usr/lib/perl/5.10.1/re.pm
+/usr/share/doc/perl/AUTHORS.gz
+/usr/share/doc/perl/Documentation
+/usr/share/doc/perl/README.Debian
+/usr/share/doc/perl/changelog.Debian.gz
+/usr/share/doc/perl/copyright
+/usr/share/lintian/overrides/perl-base
+/usr/share/man/man1/perl.1.gz
+/usr/share/man/man1/perl5.10.1.1.gz
+/usr/share/perl/5.10.1/AutoLoader.pm
+/usr/share/perl/5.10.1/Carp.pm
+/usr/share/perl/5.10.1/Carp/Heavy.pm
+/usr/share/perl/5.10.1/Exporter.pm
+/usr/share/perl/5.10.1/Exporter/Heavy.pm
+/usr/share/perl/5.10.1/File/Spec.pm
+/usr/share/perl/5.10.1/File/Spec/Unix.pm
+/usr/share/perl/5.10.1/FileHandle.pm
+/usr/share/perl/5.10.1/Getopt/Long.pm
+/usr/share/perl/5.10.1/IPC/Open2.pm
+/usr/share/perl/5.10.1/IPC/Open3.pm
+/usr/share/perl/5.10.1/SelectSaver.pm
+/usr/share/perl/5.10.1/Symbol.pm
+/usr/share/perl/5.10.1/Text/ParseWords.pm
+/usr/share/perl/5.10.1/Text/Tabs.pm
+/usr/share/perl/5.10.1/Text/Wrap.pm
+/usr/share/perl/5.10.1/Tie/Hash.pm
+/usr/share/perl/5.10.1/attributes.pm
+/usr/share/perl/5.10.1/base.pm
+/usr/share/perl/5.10.1/bytes.pm
+/usr/share/perl/5.10.1/bytes_heavy.pl
+/usr/share/perl/5.10.1/constant.pm
+/usr/share/perl/5.10.1/fields.pm
+/usr/share/perl/5.10.1/integer.pm
+/usr/share/perl/5.10.1/locale.pm
+/usr/share/perl/5.10.1/overload.pm
+/usr/share/perl/5.10.1/strict.pm
+/usr/share/perl/5.10.1/unicore/*
+/usr/share/perl/5.10.1/utf8.pm
+/usr/share/perl/5.10.1/utf8_heavy.pl
+/usr/share/perl/5.10.1/vars.pm
+/usr/share/perl/5.10.1/warnings.pm
+/usr/share/perl/5.10.1/warnings/register.pm
+A nice trick to find out the minimal set of Perl library files you will
+need to run a Perl program is
+perl -e 'do "prog.pl"; END { print "$_\n" for sort keys %INC }'
+(this will not find libraries required in runtime, unfortunately, but
+it's a minimal set) and if you want to find out all the files you can
+use something like the below
+strace perl -le 'do "x.pl"' 2>&1 \
+| perl -nle '/^open\(\"(.+?)"/ && print $1'
+(The 'strace' is Linux-specific, other similar utilities include 'truss'
+and 'ktrace'.)
+=head2 C<-DNO_MATHOMS>
+If you configure perl with C<-Accflags=-DNO_MATHOMS>, the functions from
+F<mathoms.c> will not be compiled in. Those functions are no longer used
+by perl itself; for source compatibility reasons, though, they weren't
+completely removed.
+=head1 DOCUMENTATION
+Read the manual entries before running perl.  The main documentation
+is in the pod/ subdirectory and should have been installed during the
+build process.  Type B<man perl> to get started.  Alternatively, you
+can type B<perldoc perl> to use the supplied perldoc script.  This is
+sometimes useful for finding things in the library modules.
+=head1 AUTHOR
+Original author:  Andy Dougherty doughera@lafayette.edu , borrowing very
+heavily from the original README by Larry Wall, with lots of helpful
+feedback and additions from the perl5-porters@perl.org folks.
+If you have problems, corrections, or questions, please see
+L<"Reporting Problems"> above.
+=head1 REDISTRIBUTION
+This document is part of the Perl package and may be distributed under
+the same terms as perl itself, with the following additional request:
+If you are distributing a modified version of perl (perhaps as part of
+a larger package) please B<do> modify these installation instructions
+and the contact information to match your distribution.

Mercurial > repo

comparison perl-5.22.2/INSTALL @ 8045:a16537d2fe07