X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=INSTALL;h=a3093b80620e96eadb3b8ef5818beb9fd7a9c715;hb=30ef33217aeee51ee47b2433e9384b011646254a;hp=156fdd90ed6a0dca40e8f24112f6452318284a60;hpb=4fdae80067c447c675a6ac92c7959d2206e207ba;p=p5sagit%2Fp5-mst-13.2.git
diff --git a/INSTALL b/INSTALL
index 156fdd9..a3093b8 100644
--- a/INSTALL
+++ b/INSTALL
@@ -4,64 +4,210 @@ Install - Build and Installation guide for perl5.
=head1 SYNOPSIS
- ****************************
- *** NEEDS WORK FOR 5.004 ***
- ****************************
+First, make sure you are installing an up-to-date version of Perl. If
+you didn't get your Perl source from CPAN, check the latest version at
+.
-The basic steps to build and install perl5 on a Unix system are:
+The basic steps to build and install perl5 on a Unix system
+with all the defaults are:
- rm -f config.sh
- sh Configure
+ rm -f config.sh Policy.sh
+ sh Configure -de
make
make test
make install
- # possibly add these:
- (cd /usr/include && h2ph *.h sys/*.h)
- cd pod; make html && mv *.html && cd ..
- cd pod; make tex && && cd ..
+ # You may also wish to add these:
+ (cd /usr/include && h2ph *.h sys/*.h)
+ (installhtml --help)
+ (cd pod && make tex && )
Each of these is explained in further detail below.
-For information on non-Unix systems, see the section on
-L<"Porting Information">, below.
+B: starting from the release 5.6.0, Perl will use a version
+scheme where even-numbered subreleases (like 5.6) are stable
+maintenance releases and odd-numbered subreleases (like 5.7) 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.
-=head1 DESCRIPTION
+The above commands will install Perl to /usr/local or /opt, depending
+on the platform. If that's not okay with you, use
+
+ rm -f config.sh Policy.sh
+ sh Configure
+ make
+ make test
+ make install
-You should probably at least skim through this entire document before
-proceeding. Special notes specific to this release are identified
-by B.
+For information on non-Unix systems, see the section on L<"Porting
+information"> below.
+
+If "make install" just says "`install' is up to date" or something
+similar, you may be on case-preserving filesystems such as Mac's HFS+
+and you should say "make install-all". (This confusion brought to you
+by the Perl distribution having a file called INSTALL.)
+
+If you have problems, corrections, or questions, please see
+L<"Reporting Problems"> below.
+
+For information on what's new in this release, see the
+pod/perldelta.pod file. For more detailed information about specific
+changes, see the Changes file.
+
+=head1 DESCRIPTION
This document is written in pod format as an easy way to indicate its
structure. The pod format is described in pod/perlpod.pod, but you can
-read it as is with any pager or editor.
+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 embolden text, used for switches, programs or commands
+ C literal code
+ L A link (cross reference) to name
+
+Although most of the defaults are probably fine for most users,
+you should probably at least skim through this entire document before
+proceeding.
If you're building Perl on a non-Unix system, you should also read
the README file specific to your operating system, since this may
-provide additional or different instructions for building Perl.
+provide additional or different instructions for building Perl. There
+are also README files for several flavors of Unix systems, such as
+Solaris, HP-UX, and AIX; if you have one of those systems, you should
+also read the README file specific to that system.
-=head1 Space Requirements.
+If there is a hint file for your system (in the hints/ directory) you
+should also read that hint file for specific information for your
+system. (Unixware users should use the svr4.sh hint file.) If
+there is a README file for your platform, then you should read
+that too. Additional information is in the Porting/ directory.
-The complete perl5 source tree takes up about 7 MB of disk space.
-The complete tree after completing C takes roughly
-15 MB, though the actual total is likely to be quite
-system-dependent. The installation directories need something
-on the order of 7 MB, though again that value is system-dependent.
+=head1 WARNING: This version requires an extra step to build old extensions.
-=head1 Start with a Fresh Distribution.
+5.005_53 and later releases do not export unadorned
+global symbols anymore. This means you may need to build rather old
+extensions that have not been updated for the current naming convention
+with:
+
+ perl Makefile.PL POLLUTE=1
+
+Alternatively, you can enable CPP symbol pollution wholesale by
+building perl itself with:
+
+ sh Configure -Accflags=-DPERL_POLLUTE
+
+pod/perl56delta.pod contains more details about this.
+
+=head1 WARNING: This version is not binary compatible with releases of
+Perl prior to 5.8.0.
+
+If you have built extensions (ie modules that include C code)
+using an earlier version of Perl, you will need to rebuild and reinstall
+those extensions.
+
+Pure perl modules without XS or C code should continue to work fine
+without reinstallation. See the discussions below on
+L<"Coexistence with earlier versions of perl5"> and
+L<"Upgrading from 5.005 to 5.6"> for more details.
+
+The standard extensions supplied with Perl will be handled automatically.
+
+On a related issue, old modules may possibly be affected by the
+changes in the Perl language in the current release. Please see
+pod/perldelta.pod (and the earlier pod/perl5Xdelta.pod) for a description of
+what's changed. See your installed copy of the perllocal.pod
+file for a (possibly incomplete) list of locally installed modules.
+Also see CPAN::autobundle for one way to make a "bundle" of your
+currently installed modules.
+
+=head1 WARNING: This version requires a compiler that supports ANSI C.
+
+Most C compilers are now ANSI-compliant. However, a few current
+computers are delivered with an older C compiler expressly for
+rebuilding the system kernel, or for some other historical reason.
+Alternatively, you may have an old machine which was shipped before
+ANSI compliance became widespread. Such compilers are not suitable
+for building Perl.
+
+If you find that your default C compiler is not ANSI-capable, but you
+know that an ANSI-capable compiler is installed on your system, you
+can tell F to use the correct compiler by means of the
+C<-Dcc=> command-line option -- see L<"gcc">.
+
+If do not have an ANSI-capable compiler there are several avenues open
+to you:
+
+=over 4
+
+=item *
+
+You may try obtaining GCC, available from GNU mirrors worldwide,
+listed at . If, rather than
+building gcc from source code, you locate a binary version configured
+for your platform, be sure that it is compiled for the version of the
+operating system that you are using.
+
+=item *
+
+You may purchase a commercial ANSI C compiler from your system
+supplier or elsewhere. (Or your organization may already have
+licensed such software -- ask your colleagues to find out how to
+access it.) If there is a README file for your system in the Perl
+distribution (for example, F), it may contain advice on
+suitable compilers.
+
+=item *
+
+Another alternative may be to use a tool like ansi2knr to convert the
+sources back to K&R style, but there is no guarantee this route will get
+you anywhere, since the prototypes are not the only ANSI features used
+in the Perl sources. ansi2knr is usually found as part of the freely
+available Ghostscript distribution. Another similar tool is
+unprotoize, distributed with GCC. Since unprotoize requires GCC to
+run, you may have to run it on a platform where GCC is available, and move
+the sources back to the platform without GCC.
+
+If you succeed in automatically converting the sources to a K&R compatible
+form, be sure to email perlbug@perl.org to let us know the steps you
+followed. This will enable us to officially support this option.
+
+=back
+
+Although Perl can be compiled using a C++ compiler, the Configure script
+does not work with some C++ compilers.
+
+=head1 Space Requirements
+
+The complete perl5 source tree takes up about 50 MB of disk space.
+After completing make, it takes up roughly 100 MB, though the actual
+total is likely to be quite system-dependent. The installation
+directories need something on the order of 45 MB, though again that
+value is system-dependent.
+
+=head1 Start with a Fresh Distribution
If you have built perl before, you should clean out the build directory
with the command
+ make distclean
+
+or
+
make realclean
-The results of a Configure run are stored in the config.sh file. If
-you are upgrading from a previous version of perl, or if you change
-systems or compilers or make other significant changes, or if you are
-experiencing difficulties building perl, you should probably I
-re-use your old config.sh. Simply remove it or rename it, e.g.
+The only difference between the two is that make distclean also removes
+your old config.sh and Policy.sh files.
- mv config.sh config.sh.old
+The results of a Configure run are stored in the config.sh and Policy.sh
+files. If you are upgrading from a previous version of perl, or if you
+change systems or compilers or make other significant changes, or if
+you are experiencing difficulties building perl, you should probably
+not re-use your old config.sh. Simply remove it
+
+ rm -f config.sh
If you wish to use your old config.sh, be especially attentive to the
version and architecture-specific questions and answers. For example,
@@ -69,320 +215,621 @@ the default directory for architecture-dependent library modules
includes the version name. By default, Configure will reuse your old
name (e.g. /opt/perl/lib/i86pc-solaris/5.003) even if you're running
Configure for a different version, e.g. 5.004. Yes, Configure should
-probably check and correct for this, but it doesn't, presently.
+probably check and correct for this, but it doesn't.
Similarly, if you used a shared libperl.so (see below) with version
numbers, you will probably want to adjust them as well.
-Also, be careful to check your architecture name. Some Linux systems
-call themselves i486, while others use i586. If you pick up a
-precompiled binary, it might not use the same name.
+Also, be careful to check your architecture name. For example, some
+Linux distributions use i386, while others may use i486. If you build
+it yourself, Configure uses the output of the arch command, which
+might be i586 or i686 instead. If you pick up a precompiled binary, or
+compile extensions on different systems, they might not all agree on
+the architecture name.
In short, if you wish to use your old config.sh, I recommend running
Configure interactively rather than blindly accepting the defaults.
-=head1 Run Configure.
+If your reason to reuse your old config.sh is to save your particular
+installation choices, then you can probably achieve the same effect by
+using the Policy.sh file. See the section on L<"Site-wide Policy
+settings"> below. If you wish to start with a fresh distribution, you
+also need to remove any old Policy.sh files you may have with
+
+ rm -f Policy.sh
+
+=head1 Run Configure
Configure will figure out various things about your system. Some
things Configure will figure out for itself, other things it will ask
-you about. To accept the default, just press C. The default
-is almost always ok.
+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
-F<*.SH> files and offer to run B.
+*.SH files and offer to run make depend.
+
+=head2 Altering config.sh variables for C compiler switches etc.
+
+For most users, all of the Configure defaults are fine. Configure
+also has several convenient options which are all described below.
+However, if Configure doesn't have an option to do what you want,
+you can change Configure variables after the platform hints have been
+run, by using Configure's -A switch. For example, here's how to add
+a couple of extra flags to C compiler invocations:
+
+ sh Configure -Accflags="-DPERL_Y2KWARN -DPERL_POLLUTE_MALLOC"
+
+For more help on Configure switches, run:
+
+ sh Configure -h
+
+=head2 Building Perl outside of the source directory
-Configure supports a number of useful options. Run B
-to get a listing. To compile with gcc, for example, you can run
+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.
+
+Starting from Perl 5.6.1 you can do this (if your file system supports
+symbolic links) by
+
+ mkdir /tmp/perl/build/directory
+ cd /tmp/perl/build/directory
+ sh /path/to/perl/source/Configure -Dmksymlinks ...
+
+This will create in /tmp/perl/build/directory a tree of symbolic links
+pointing to files in /path/to/perl/source. The original files are left
+unaffected. After Configure has finished you can just say
+
+ make all test
+
+and Perl will be built and tested, all in /tmp/perl/build/directory.
+
+=head2 Common Configure options
+
+Configure supports a number of useful options. Run B to
+get a listing. See the Porting/Glossary file for a complete list of
+Configure variables you can set and their definitions.
+
+=over 4
+
+=item gcc
+
+To compile with gcc you should run
sh Configure -Dcc=gcc
This is the preferred way to specify gcc (or another alternative
compiler) so that the hints files can set appropriate defaults.
+=item Installation prefix
+
+By default, for most systems, perl will be installed in
+/usr/local/{bin, lib, man}. (See L<"Installation Directories">
+and L<"Coexistence with earlier versions of perl5"> below for
+further details.)
+
+You can specify a different 'prefix' for the default installation
+directory, when Configure prompts you or by using the Configure command
+line option -Dprefix='/some/directory', e.g.
+
+ sh Configure -Dprefix=/opt/perl
+
+If your prefix contains the string "perl", then the suggested
+directory structure is simplified. For example, if you use
+prefix=/opt/perl, then Configure will suggest /opt/perl/lib instead of
+/opt/perl/lib/perl5/. Again, see L<"Installation Directories"> below
+for more details. Do not include a trailing slash, (i.e. /opt/perl/)
+or you may experience odd test failures.
+
+NOTE: You must not specify an installation directory that is the same
+as or below your perl source directory. If you do, installperl will
+attempt infinite recursion.
+
+=item /usr/bin/perl
+
+It may seem obvious, but Perl is useful only when users can easily
+find it. It's often a good idea to have both /usr/bin/perl and
+/usr/local/bin/perl be symlinks to the actual binary. Be especially
+careful, however, not to overwrite a version of perl supplied by your
+vendor unless you are sure you know what you are doing.
+
+By default, Configure will arrange for /usr/bin/perl to be linked to
+the current version of perl. You can turn off that behavior by running
+
+ Configure -Uinstallusrbinperl
+
+or by answering 'no' 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 Overriding an old config.sh
+
If you want to use your old config.sh but override some of the items
with command line options, you need to use B.
+=back
+
If you are willing to accept all the defaults, and you want terse
output, you can run
sh Configure -des
-By default, for most systems, perl will be installed in
-/usr/local/{bin, lib, man}. 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.
+Note: for development releases (odd subreleases, like 5.7, as opposed
+to maintenance releases which have even subreleases, like 5.6)
+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.
- sh Configure -Dprefix=/opt/perl
+For example for my Solaris system, I usually use
-If your prefix contains the string "perl", then the directories
-are simplified. For example, if you use prefix=/opt/perl,
-then Configure will suggest /opt/perl/lib instead of
-/opt/perl/lib/perl5/.
-
-By default, Configure will compile perl to use dynamic loading, if
-your system supports it. If you want to force perl to be compiled
-statically, you can either choose this when Configure prompts you or
-you can use the Configure command line option -Uusedl.
+ sh Configure -Dprefix=/opt/perl -Doptimize='-xpentium -xO4' -des
=head2 GNU-style configure
-If you prefer the GNU-style B command line interface, you can
-use the supplied B command, e.g.
+If you prefer the GNU-style configure command line interface, you can
+use the supplied configure.gnu command, e.g.
- CC=gcc ./configure
+ CC=gcc ./configure.gnu
-The B script emulates several of the more common configure
+The configure.gnu script emulates a few of the more common configure
options. Try
- ./configure --help
+ ./configure.gnu --help
for a listing.
-Cross compiling is currently not supported.
+Cross compiling and compiling in a different directory are not supported.
-For systems that do not distinguish the files "Configure" and
-"configure", Perl includes a copy of B named
-B.
+(The file is called configure.gnu to avoid problems on systems
+that would not distinguish the files "Configure" and "configure".)
-=head2 Binary Compatibility With Earlier Versions of Perl 5
+=head2 Installation Directories
-Starting with Perl 5.003, all functions in the Perl C source code have
-been protected by default by the prefix Perl_ (or perl_) so that you
-may link with third-party libraries without fear of namespace
-collisons. This change broke compatability with version 5.002, so
-installing 5.003 or 5.004 over 5.002 or earlier will force you to
-re-build and install all of your dynamically loadable extensions.
-(The standard extensions supplied with Perl are handled
-automatically). You can turn off this namespace protection by adding
--DNO_EMBED to your ccflags variable in config.sh.
+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.
+Further, there are a number of additions to the installation
+directories since 5.005, so reusing your old config.sh may not
+be sufficient to put everything where you want it. Do not include
+trailing slashes on directory names.
-Perl 5.003's namespace protection was incomplete, which has been
-rectified in Perl 5.004. However, some sites may need to maintain
-complete binary compatibility with Perl 5.003. If you are building
-Perl for such a site, then when B asks if you want binary
-compatibility, answer "y".
+I highly recommend running Configure interactively to be sure it puts
+everything where you want it. At any point during the Configure
+process, you can answer a question with &-d and Configure will use
+the defaults from then on.
-=head2 Extensions
+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.
-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. (See examples below.)
-DynaLoader, Fcntl, and IO are always built by default. Configure does
-not contain code to test for POSIX compliance, so POSIX is always built
-by default as well. If you wish to skip POSIX, you can set the
-Configure variable useposix=false either in a hint file or from the
-Configure command line. Similarly, the Opcode extension is always built
-by default, but you can skip it by setting the Configure variable
-useopcode=false either in a hint file for from the command line.
+The directories set up by Configure fall into three broad categories.
-Even if you do not have dynamic loading, you must still build the
-DynaLoader extension; you should just build the stub dl_none.xs
-version. (Configure will suggest this as the default.)
+=over 4
-In summary, here are the Configure command-line variables you can set
-to turn off each extension:
+=item Directories for the perl distribution
+
+By default, Configure will use the following directories for 5.6.0.
+$version is the full perl version number, including subversion, e.g.
+5.6.0 or 5.6.1, and $archname is a string like sun4-sunos,
+determined by Configure. The full definitions of all Configure
+variables are in the file Porting/Glossary.
+
+ Configure variable Default value
+ $prefix /usr/local
+ $bin $prefix/bin
+ $scriptdir $prefix/bin
+ $privlib $prefix/lib/perl5/$version
+ $archlib $prefix/lib/perl5/$version/$archname
+ $man1dir $prefix/man/man1
+ $man3dir $prefix/man/man3
+ $html1dir (none)
+ $html3dir (none)
+
+Actually, Configure recognizes the SVR3-style
+/usr/local/man/l_man/man1 directories, if present, and uses those
+instead. Also, if $prefix contains the string "perl", the library
+directories are simplified as described below. For simplicity, only
+the common style is shown here.
+
+=item Directories for site-specific add-on files
+
+After perl is installed, you may later wish to add modules (e.g. from
+CPAN) or scripts. Configure will set up the following directories to
+be used for installing those add-on modules and scripts.
+
+ Configure variable Default value
+ $siteprefix $prefix
+ $sitebin $siteprefix/bin
+ $sitescript $siteprefix/bin
+ $sitelib $siteprefix/lib/perl5/site_perl/$version
+ $sitearch $siteprefix/lib/perl5/site_perl/$version/$archname
+ $siteman1 $siteprefix/man/man1
+ $siteman3 $siteprefix/man/man3
+ $sitehtml1 (none)
+ $sitehtml3 (none)
+
+By default, ExtUtils::MakeMaker will install architecture-independent
+modules into $sitelib and architecture-dependent modules into $sitearch.
+
+=item Directories for vendor-supplied add-on files
+
+Lastly, if you are building a binary distribution of perl for
+distribution, Configure can optionally set up the following directories
+for you to use to distribute add-on modules.
+
+ Configure variable Default value
+ $vendorprefix (none)
+ (The next ones are set only if vendorprefix is set.)
+ $vendorbin $vendorprefix/bin
+ $vendorscript $vendorprefix/bin
+ $vendorlib $vendorprefix/lib/perl5/vendor_perl/$version
+ $vendorarch $vendorprefix/lib/perl5/vendor_perl/$version/$archname
+ $vendorman1 $vendorprefix/man/man1
+ $vendorman3 $vendorprefix/man/man3
+ $vendorhtml1 (none)
+ $vendorhtml3 (none)
+
+These are normally empty, but may be set as needed. For example,
+a vendor might choose the following settings:
+
+ $prefix /usr
+ $siteprefix /usr/local
+ $vendorprefix /usr
+
+This would have the effect of setting the following:
+
+ $bin /usr/bin
+ $scriptdir /usr/bin
+ $privlib /usr/lib/perl5/$version
+ $archlib /usr/lib/perl5/$version/$archname
+ $man1dir /usr/man/man1
+ $man3dir /usr/man/man3
+
+ $sitebin /usr/local/bin
+ $sitescript /usr/local/bin
+ $sitelib /usr/local/lib/perl5/site_perl/$version
+ $sitearch /usr/local/lib/perl5/site_perl/$version/$archname
+ $siteman1 /usr/local/man/man1
+ $siteman3 /usr/local/man/man3
+
+ $vendorbin /usr/bin
+ $vendorscript /usr/bin
+ $vendorlib /usr/lib/perl5/vendor_perl/$version
+ $vendorarch /usr/lib/perl5/vendor_perl/$version/$archname
+ $vendorman1 /usr/man/man1
+ $vendorman3 /usr/man/man3
+
+Note how in this example, the vendor-supplied directories are in the
+/usr hierarchy, while the directories reserved for the end-user are in
+the /usr/local hierarchy.
+
+The entire installed library hierarchy is installed in locations with
+version numbers, keeping the installations of different versions distinct.
+However, later installations of Perl can still be configured to search the
+installed libraries corresponding to compatible earlier versions.
+See L<"Coexistence with earlier versions of perl5"> below for more details
+on how Perl can be made to search older version directories.
+
+Of course you may use these directories however you see fit. For
+example, you may wish to use $siteprefix for site-specific files that
+are stored locally on your own disk and use $vendorprefix for
+site-specific files that are stored elsewhere on your organization's
+network. One way to do that would be something like
+
+ sh Configure -Dsiteprefix=/usr/local -Dvendorprefix=/usr/share/perl
+
+=item otherlibdirs
+
+As a final catch-all, Configure also offers an $otherlibdirs
+variable. This variable contains a colon-separated list of additional
+directories to add to @INC. By default, it will be empty.
+Perl will search these directories (including architecture and
+version-specific subdirectories) for add-on modules and extensions.
+
+=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,
+ahead of any others, and so provide a way to override the standard perl
+modules should you, for example, want to distribute fixes without
+touching the perl distribution proper. And, like otherlib dirs,
+version and architecture specific subdirectories are also searched, if
+present, at run time. Of course, you can still search other @INC
+directories ahead of those in APPLLIB_EXP by using any of the standard
+run-time methods: $PERLLIB, $PERL5LIB, -I, use lib, etc.
+
+=item Man Pages
+
+In versions 5.005_57 and earlier, the default was to store module man
+pages in a version-specific directory, such as
+/usr/local/lib/perl5/$version/man/man3. The default for 5.005_58 and
+after is /usr/local/man/man3 so that most users can find the man pages
+without resetting MANPATH.
+
+You can continue to use the old default from the command line with
+
+ sh Configure -Dman3dir=/usr/local/lib/perl5/5.6.0/man/man3
+
+Some users also prefer to use a .3pm suffix. You can do that with
+
+ sh Configure -Dman3ext=3pm
- DB_File i_db
- DynaLoader (Must always be included as a static extension)
- Fcntl (Always included by default)
- GDBM_File i_gdbm
- IO (Always included by default)
- NDBM_File i_ndbm
- ODBM_File i_dbm
- POSIX useposix
- SDBM_File (Always included by default)
- Opcode useopcode
- Socket d_socket
+Again, these are just the defaults, and can be changed as you run
+Configure.
-Thus to skip the NDBM_File extension, you can use
+=item HTML pages
- sh Configure -Ui_ndbm
+As of perl5.005_57, 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.
-Again, this is taken care of automatically if you don't have the ndbm
-library.
+=back
-Of course, you may always run Configure interactively and select only
-the Extensions you want.
+Some users prefer to append a "/share" to $privlib and $sitelib
+to emphasize that those directories can be shared among different
+architectures.
-Finally, if you have dynamic loading (most modern Unix systems do)
-remember that these extensions do not increase the size of your perl
-executable, nor do they impact start-up time, so you probably might as
-well build all the ones that will work on your system.
+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.
-=head2 Including locally-installed libraries
+Further details about the installation directories, maintenance and
+development subversions, and about supporting multiple versions are
+discussed in L<"Coexistence with earlier versions of perl5"> below.
-Perl5 comes with interfaces to number of database extensions, including
-dbm, ndbm, gdbm, and Berkeley db. For each extension, if
-Configure can find the appropriate header files and libraries, it will
-automatically include that extension. The gdbm and db libraries
-are B included with perl. See the library documentation for
-how to obtain the libraries.
+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.
-I If your database header (.h) files are not in a
-directory normally searched by your C compiler, then you will need to
-include the appropriate B<-I/your/directory> option when prompted by
-Configure. If your database library (.a) files are not in a directory
-normally searched by your C compiler and linker, then you will need to
-include the appropriate B<-L/your/directory> option when prompted by
-Configure. See the examples below.
+Thus, for example, if you Configure with
+-Dprefix=/opt/perl, then the default library directories for 5.6.0 are
-=head2 Examples
+ Configure variable Default value
+ $privlib /opt/perl/lib/5.6.0
+ $archlib /opt/perl/lib/5.6.0/$archname
+ $sitelib /opt/perl/lib/site_perl/5.6.0
+ $sitearch /opt/perl/lib/site_perl/5.6.0/$archname
-=over 4
+=head2 Changing the installation directory
-=item gdbm in /usr/local.
+Configure distinguishes between the directory in which perl (and its
+associated files) should be installed and the directory in which it
+will eventually reside. For most sites, these two are the same; for
+sites that use AFS, this distinction is handled automatically.
+However, sites that use software such as depot to manage software
+packages, or users building binary packages for distribution may also
+wish to install perl into a different directory and use that
+management software to move perl to its final destination. This
+section describes how to do that.
-Suppose you have gdbm and want Configure to find it and build the
-GDBM_File extension. This examples assumes you have F
-installed in F and F installed in
-F. Configure should figure all the
-necessary steps out automatically.
+Suppose you want to install perl under the /tmp/perl5 directory. You
+could edit config.sh and change all the install* variables to point to
+/tmp/perl5 instead of /usr/local, or you could simply use the
+following command line:
-Specifically, when Configure prompts you for flags for
-your C compiler, you should include C<-I/usr/local/include>.
+ sh Configure -Dinstallprefix=/tmp/perl5
-When Configure prompts you for linker flags, you should include
-C<-L/usr/local/lib>.
+(replace /tmp/perl5 by a directory of your choice).
-If you are using dynamic loading, then when Configure prompts you for
-linker flags for dynamic loading, you should again include
-C<-L/usr/local/lib>.
+Beware, though, that if you go to try to install new add-on
+modules, they too will get installed in under '/tmp/perl5' if you
+follow this example. The next section shows one way of dealing with
+that problem.
-Again, this should all happen automatically. If you want to accept the
-defaults for all the questions and have Configure print out only terse
-messages, then you can just run
+=head2 Creating an installable tar archive
- sh Configure -des
+If you need to install perl on many identical systems, it is
+convenient to compile it once and create an archive that can be
+installed on multiple systems. Suppose, for example, that you want to
+create an archive that can be installed in /opt/perl.
+Here's one way to do that:
-and Configure should include the GDBM_File extension automatically.
+ # Set up to install perl into a different directory,
+ # e.g. /tmp/perl5 (see previous part).
+ sh Configure -Dinstallprefix=/tmp/perl5 -Dprefix=/opt/perl -des
+ make
+ make test
+ make install # This will install everything into /tmp/perl5.
+ cd /tmp/perl5
+ # Edit $archlib/Config.pm and $archlib/.packlist to change all the
+ # install* variables back to reflect where everything will
+ # really be installed. (That is, change /tmp/perl5 to /opt/perl
+ # everywhere in those files.)
+ # Check the scripts in $scriptdir to make sure they have the correct
+ # #!/wherever/perl line.
+ tar cvf ../perl5-archive.tar .
+ # Then, on each machine where you want to install perl,
+ cd /opt/perl # Or wherever you specified as $prefix
+ tar xvf perl5-archive.tar
-This should actually work if you have gdbm installed in any of
-(/usr/local, /opt/local, /usr/gnu, /opt/gnu, /usr/GNU, or /opt/GNU).
+=head2 Site-wide Policy settings
-=item gdbm in /usr/you
+After Configure runs, it stores a number of common site-wide "policy"
+answers (such as installation directories and the local perl contact
+person) in the Policy.sh file. If you want to build perl on another
+system using the same policy defaults, simply copy the Policy.sh file
+to the new system and Configure will use it along with the appropriate
+hint file for your system.
-Suppose you have gdbm installed in some place other than /usr/local/,
-but you still want Configure to find it. To be specific, assume you
-have F and F. You
-still have to add B<-I/usr/you/include> to cc flags, but you have to take
-an extra step to help Configure find F. Specifically, when
-Configure prompts you for library directories, you have to add
-F to the list.
+Alternatively, if you wish to change some or all of those policy
+answers, you should
-It is possible to specify this from the command line too (all on one
-line):
+ rm -f Policy.sh
- sh Configure -des \
- -Dlocincpth="/usr/you/include" \
- -Dloclibpth="/usr/you/lib"
+to ensure that Configure doesn't re-use them.
-C is a space-separated list of include directories to search.
-Configure will automatically add the appropriate B<-I> directives.
+Further information is in the Policy_sh.SH file itself.
-C is a space-separated list of library directories to search.
-Configure will automatically add the appropriate B<-L> directives. If
-you have some libraries under F and others under
-F, then you have to include both, namely
+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.
- sh Configure -des \
- -Dlocincpth="/usr/you/include /usr/local/include" \
- -Dloclibpth="/usr/you/lib /usr/local/lib"
+Note: Since the directory hierarchy for 5.6.0 contains a number of
+new vendor* and site* entries, your Policy.sh file will probably not
+set them to your desired values. I encourage you to run Configure
+interactively to be sure it puts things where you want them.
-=back
+=head2 Configure-time Options
-=head2 Installation Directories.
+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.
-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.
+=head2 Threads
-By default, Configure uses the following directories for
-library files (archname is a string like sun4-sunos, determined
-by Configure)
+On some platforms, perl5.005 and later can be compiled with
+experimental support for threads. To enable this, read the file
+ext/threads/threads.pm, and then try:
- /usr/local/lib/perl5/archname/5.004
- /usr/local/lib/perl5/
- /usr/local/lib/perl5/site_perl/archname
- /usr/local/lib/perl5/site_perl
+ sh Configure -Dusethreads
-and the following directories for manual pages:
+Currently, you need to specify -Dusethreads on the Configure command
+line so that the hint files can make appropriate adjustments.
- /usr/local/man/man1
- /usr/local/lib/perl5/man/man3
+The default is to compile without thread support.
-(Actually, Configure recognizes the SVR3-style
-/usr/local/man/l_man/man1 directories, if present, and uses those
-instead.) The module man pages are stuck in that strange spot so that
-they don't collide with other man pages stored in /usr/local/man/man3,
-and so that Perl's man pages don't hide system man pages. On some
-systems, B would end up calling up Perl's less.pm module man
-page, rather than the B program.
+Perl has two different internal threads implementations. The current
+model (available internally since 5.6, and as a user-level module
+since 5.8) is called interpreter-based implementation (ithreads),
+with one interpreter per thread, and explicit sharing of data.
-If you specify a prefix that contains the string "perl", then the
-directory structure is simplified. For example, if you Configure
-with -Dprefix=/opt/perl, then the defaults are
-
- /opt/perl/lib/archname/5.004
- /opt/perl/lib
- /opt/perl/lib/site_perl/archname
- /opt/perl/lib/site_perl
-
- /opt/perl/man/man1
- /opt/perl/man/man3
-
-The perl executable will search the libraries in the order given
-above.
-
-The directories site_perl and site_perl/archname are empty, but are
-intended to be used for installing local or site-wide extensions. Perl
-will automatically look in these directories. Previously, most sites
-just put their local extensions in with the standard distribution.
-
-In order to support using things like #!/usr/local/bin/perl5.004 after
-a later version is released, architecture-dependent libraries are
-stored in a version-specific directory, such as
-/usr/local/lib/perl5/archname/5.004/. In Perl 5.000 and 5.001, these
-files were just stored in /usr/local/lib/perl5/archname/. If you will
-not be using 5.001 binaries, you can delete the standard extensions from
-the /usr/local/lib/perl5/archname/ directory. Locally-added extensions
-can be moved to the site_perl and site_perl/archname directories.
+The 5.005 version (5005threads) is considered obsolete, buggy, and
+unmaintained.
-Again, these are just the defaults, and can be changed as you run
-Configure.
+By default, Configure selects ithreads if -Dusethreads is specified.
-=head2 Selecting File IO mechanisms
+(You need to use also the PerlIO layer, explained later, if you decide
+to use ithreads, to guarantee the good interworking of threads and I/O.)
-Previous versions of perl used the standard IO mechanisms as defined in
-. Versions 5.003_02 and later of perl allow alternate IO
-mechanisms via a "PerlIO" abstraction, but the stdio mechanism is still
-the default and is the only supported mechanism.
+However, you can select the old 5005threads behavior
-This PerlIO abstraction can be enabled either on the Configure command
-line with
+ sh Configure -Dusethreads -Duse5005threads
- sh Configure -Duseperlio
+If you decide to use ithreads, the 'threads' module allows their use,
+and the 'Thread' module offers an interface to both 5005threads and
+ithreads (whichever has been configured).
-or interactively at the appropriate Configure prompt.
+=head2 Large file support.
-If you choose to use the PerlIO abstraction layer, there are two
-(experimental) possibilities for the underlying IO calls. These have been
-tested to some extent on some platforms, but are not guaranteed to work
-everywhere.
+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.
-=over 4
+This is both good and bad. It is good in that you can use large files,
+seek(), stat(), and -s them. It is bad in that if you are interfacing Perl
+using some extension, the components you are connecting to must also
+be large file aware: if Perl thinks files can be large but the other
+parts of the software puzzle do not understand the concept, bad things
+will happen. One popular extension suffering from this ailment is the
+Apache extension mod_perl.
-=item 1.
+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.
-AT&T's "sfio". This has superior performance to in many
-cases, and is extensible by the use of "disipline" modules. Sfio
-currently only builds on a subset of the UNIX platforms perl supports.
-Because the data structures are completely different from stdio, perl
-extension modules or external libraries may not work. This
-configuration exists to allow these issues to be worked on.
+=head2 64 bit support.
+
+If your platform does not have 64 bits natively, but can simulate them
+with compiler flags and/or C or C, 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 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 Cs (it might,
+but it doesn't have to): the C means that you will be
+able to have 64 bits wide scalar values.
+
+The C goes all the way by attempting to switch also
+integers (if it can), longs (and pointers) to being 64-bit. This may
+create an even more binary incompatible Perl than -Duse64bitint: the
+resulting executable may not run at all in a 32-bit box, or you may
+have to reboot/reconfigure/rebuild your operating system to be 64-bit
+aware.
+
+Natively 64-bit systems like Alpha and Cray need neither -Duse64bitint
+nor -Duse64bitall.
+
+ NOTE: 64-bit support is still experimental on most platforms.
+ Existing support only covers the LP64 data model. In particular, the
+ LLP64 data model is not yet supported. 64-bit libraries and system
+ APIs on many platforms have not stabilized--your mileage may vary.
+
+=head2 Long doubles
+
+In some systems you may be able to use long doubles to enhance the
+range and precision of your double precision floating point numbers
+(that is, Perl's numbers). Use Configure -Duselongdouble to enable
+this support (if it is available).
+
+=head2 "more bits"
+
+You can "Configure -Dusemorebits" to turn on both the 64-bit support
+and the long double support.
+
+=head2 Selecting File IO mechanisms
+
+Executive summary: in Perl 5.8, you should use the default "PerlIO"
+as the IO mechanism unless you have a good reason not to.
+
+In more detail: previous versions of perl used the standard IO
+mechanisms as defined in stdio.h. Versions 5.003_02 and later of perl
+introduced alternate IO mechanisms via a "PerlIO" abstraction, but up
+until and including Perl 5.6, the stdio mechanism was still the default
+and the only supported mechanism.
+
+Starting from Perl 5.8, the default mechanism is to use the PerlIO
+abstraction, because it allows better control of I/O mechanisms,
+instead of having to work with (often, work around) vendors' I/O
+implementations.
+
+This PerlIO abstraction can be (but again, unless you know what you
+are doing, should not be) disabled either on the Configure command
+line with
+
+ sh Configure -Uuseperlio
+
+or interactively at the appropriate Configure prompt.
+
+With the PerlIO abstraction layer, there is another possibility for
+the underlying IO calls, AT&T's "sfio". This has superior performance
+to stdio.h in many cases, and is extensible by the use of "discipline"
+modules ("Native" PerlIO has them too). Sfio currently only builds on
+a subset of the UNIX platforms perl supports. Because the data
+structures are completely different from stdio, perl extension modules
+or external libraries may not work. This configuration exists to
+allow these issues to be worked on.
This option requires the 'sfio' package to have been built and installed.
-A (fairly old) version of sfio is in CPAN, and work is in progress to make
-it more easily buildable by adding Configure support.
+The latest sfio is available from http://www.research.att.com/sw/tools/sfio/
You select this option by
@@ -392,64 +839,28 @@ If you have already selected -Duseperlio, and if Configure detects
that you have sfio, then sfio will be the default suggested by
Configure.
-=item 2.
-
-Normal stdio IO, but with all IO going through calls to the PerlIO
-abstraction layer. This configuration can be used to check that perl and
-extension modules have been correctly converted to use the PerlIO
-abstraction.
+Note: On some systems, sfio's iffe configuration script fails to
+detect that you have an atexit function (or equivalent). Apparently,
+this is a problem at least for some versions of Linux and SunOS 4.
+Configure should detect this problem and warn you about problems with
+_exit vs. exit. If you have this problem, the fix is to go back to
+your sfio sources and correct iffe's guess about atexit.
-This configuration should work on all platforms (but might not).
+=head2 SOCKS
-You select this option via :
+Perl can be configured to be 'socksified', that is, to use the SOCKS
+TCP/IP proxy protocol library. SOCKS is used to give applications
+access to transport layer network proxies. Perl supports only SOCKS
+Version 5. You can find more about SOCKS from http://www.socks.nec.com/
- sh Configure -Duseperlio -Uusesfio
+=head2 Dynamic Loading
-If you have already selected -Duseperlio, and if Configure does not
-detect sfio, then this will be the default suggested by Configure.
-
-=back
-
-=head2 Changing the installation directory
-
-Configure distinguishes between the directory in which perl (and its
-associated files) should be installed and the directory in which it
-will eventually reside. For most sites, these two are the same; for
-sites that use AFS, this distinction is handled automatically.
-However, sites that use software such as B to manage software
-packages may also wish to install perl into a different directory and
-use that management software to move perl to its final destination.
-This section describes how to do this. Someday, Configure may support
-an option C<-Dinstallprefix=/foo> to simplify this.
-
-Suppose you want to install perl under the F directory.
-You can edit F and change all the install* variables to
-point to F instead of F. You could
-also set them all from the Configure command line. Or, you can
-automate this process by placing the following lines in a file
-F B you run Configure (replace /tmp/perl5 by a
-directory of your choice):
-
- installprefix=/tmp/perl5
- test -d $installprefix || mkdir $installprefix
- test -d $installprefix/bin || mkdir $installprefix/bin
- installarchlib=`echo $installarchlib | sed "s!$prefix!$installprefix!"`
- installbin=`echo $installbin | sed "s!$prefix!$installprefix!"`
- installman1dir=`echo $installman1dir | sed "s!$prefix!$installprefix!"`
- installman3dir=`echo $installman3dir | sed "s!$prefix!$installprefix!"`
- installprivlib=`echo $installprivlib | sed "s!$prefix!$installprefix!"`
- installscript=`echo $installscript | sed "s!$prefix!$installprefix!"`
- installsitelib=`echo $installsitelib | sed "s!$prefix!$installprefix!"`
- installsitearch=`echo $installsitearch | sed "s!$prefix!$installprefix!"`
-
-Then, you can Configure and install in the usual way:
-
- sh Configure -des
- make
- make test
- make install
+By default, Configure will compile perl to use dynamic loading if
+your system supports it. If you want to force perl to be compiled
+statically, you can either choose this when Configure prompts you or
+you can use the Configure command line option -Uusedl.
-=head2 Building a shared libperl.so Perl library.
+=head2 Building a shared Perl library
Currently, for most systems, the main perl executable is built by
linking the "perl library" libperl.a with perlmain.o, your static
@@ -465,7 +876,7 @@ 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
-meachanism is still rather fragile with respect to different versions
+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
@@ -487,9 +898,28 @@ You can elect to build a shared libperl by
sh Configure -Duseshrplib
-To actually build perl, you must add the current working directory to your
-LD_LIBRARY_PATH environtment variable before running make. You can do
-this with
+To build a shared libperl, the environment variable controlling shared
+library search (LD_LIBRARY_PATH in most systems, DYLD_LIBRARY_PATH for
+NeXTSTEP/OPENSTEP/Darwin, LIBRARY_PATH for BeOS, LD_LIBRARY_PATH/SHLIB_PATH
+for HP-UX, LIBPATH for AIX, PATH for Cygwin) must be set up to include
+the Perl build directory because that's where the shared libperl will
+be created. Configure arranges makefile to have the correct shared
+library search settings. You can find the name of the environment
+variable Perl thinks works in your your system by
+
+ grep ldlibpthname config.sh
+
+However, there are some special cases where manually setting the
+shared library path might be required. For example, if you want to run
+something like the following with the newly-built but not-yet-installed
+./perl:
+
+ cd t; ./perl misc/failing_test.t
+or
+ ./perl -Ilib ~/my_mission_critical_test
+
+then you need to set up the shared library path explicitly.
+You can do this with
LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
@@ -497,9 +927,14 @@ for Bourne-style shells, or
setenv LD_LIBRARY_PATH `pwd`
-for Csh-style shells. You *MUST* do this before running make.
-Folks running NeXT OPENSTEP must substitute DYLD_LIBRARY_PATH for
-LD_LIBRARY_PATH above.
+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.
@@ -512,34 +947,267 @@ libperl.so.4 rather with the installed libperl.so.4? 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't.
+with LD_LIBRARY_PATH; on Linux you can't. On Digital Unix, you can
+override LD_LIBRARY_PATH by setting the _RLD_ROOT environment variable
+to point to the perl build directory.
The only reliable answer is that you should specify a different
directory for the architecture-dependent library for your -DDEBUGGING
-version of perl. You can do this with by changing all the *archlib*
-variables in config.sh, namely archlib, archlib_exp, and
-installarchlib, to point to your new architecture-dependent library.
+version of perl. You can do this by changing all the *archlib*
+variables in config.sh to point to your new architecture-dependent library.
-=head2 Creating an installable tar archive
+=head2 Malloc Issues
-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. Here's one way to do that:
+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.
- # Set up config.over to install perl into a different directory,
- # e.g. /tmp/perl5 (see previous part).
- sh Configure -des
- make
- make test
- make install
- cd /tmp/perl5
- tar cvf ../perl5-archive.tar .
- # Then, on each machine where you want to install perl,
- cd /usr/local # Or wherever you specified as $prefix
- tar xvf perl5-archive.tar
+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.
+
+=item -DPERL_POLLUTE_MALLOC
+
+NOTE: This flag is enabled automatically on some platforms if you just
+run Configure to accept all the defaults on those platforms.
+
+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.
+
+=back
+
+=head2 Building a debugging perl
+
+You can run perl scripts under the perl debugger at any time with
+B. If, however, you want to debug perl itself,
+you probably want to do
+
+ sh Configure -Doptimize='-g'
+
+This will do two independent things: First, it will force compilation
+to use cc -g so that you can use your system's debugger on the
+executable. (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.) Second, it will add -DDEBUGGING to your ccflags
+variable in config.sh so that you can use B to access perl's
+internal state. (Note: Configure will only add -DDEBUGGING by default
+if you are not reusing your old config.sh. If you want to reuse your
+old config.sh, then you can just edit it and change the optimize and
+ccflags variables by hand and then propagate your changes as shown in
+L<"Propagating your changes to config.sh"> below.)
+
+You can actually specify -g and -DDEBUGGING independently, but usually
+it's convenient to have both.
+
+If you are using a shared libperl, see the warnings about multiple
+versions of perl under L.
+
+=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. (See examples below.)
+Configure does not contain code to test for POSIX compliance, so POSIX
+is always built by default as well. If you wish to skip POSIX, you can
+set the Configure variable useposix=false either in a hint file or from
+the Configure command line.
+
+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.)
+
+You can learn more about each of the supplied extensions by consulting the
+documentation in the individual .pm modules, located under the
+ext/ subdirectory.
+
+Even if you do not have dynamic loading, you must still build the
+DynaLoader extension; you should just build the stub dl_none.xs
+version. (Configure will suggest this as the default.)
+
+In summary, here are the Configure command-line variables you can set
+to turn off various extensions. All others are included by default.
+
+ DB_File i_db
+ DynaLoader (Must always be included as a static extension)
+ GDBM_File i_gdbm
+ NDBM_File i_ndbm
+ ODBM_File i_dbm
+ POSIX useposix
+ Opcode useopcode
+ Socket d_socket
+ Threads use5005threads
+
+Thus to skip the NDBM_File extension, you can use
+
+ sh Configure -Ui_ndbm
+
+Again, this is taken care of automatically if you don't have the ndbm
+library.
+
+Of course, you may always run Configure interactively and select only
+the extensions you want.
+
+Note: The DB_File module will only work with version 1.x of Berkeley
+DB or newer releases of version 2. Configure will automatically detect
+this for you and refuse to try to build DB_File with earlier
+releases of version 2.
+
+If you re-use your 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.
+
+Finally, if you have dynamic loading (most modern systems do)
+remember that these extensions do not increase the size of your perl
+executable, nor do they impact start-up time, so you probably might as
+well build all the ones that will work on your system.
+
+=head2 Including locally-installed libraries
+
+Perl5 comes with interfaces to number of database extensions, including
+dbm, ndbm, gdbm, and Berkeley db. For each extension, if
+Configure can find the appropriate header files and libraries, it will
+automatically include that extension. The gdbm and db libraries
+are not included with perl. See the library documentation for
+how to obtain the libraries.
+
+If your database header (.h) files 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 database library (.a) files 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.
+
+=head2 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.
+
+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 gdbm in /usr/you
+
+Suppose you have gdbm installed in some place other than /usr/local/,
+but you still want Configure to find it. To be specific, assume you
+have /usr/you/include/gdbm.h and /usr/you/lib/libgdbm.a. You
+still have to add -I/usr/you/include to cc flags, but you have to take
+an extra step to help Configure find libgdbm.a. Specifically, when
+Configure prompts you for library directories, you have to add
+/usr/you/lib to the list.
+
+It is possible to specify this from the command line too (all on one
+line):
+
+ sh Configure -de \
+ -Dlocincpth="/usr/you/include" \
+ -Dloclibpth="/usr/you/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. If
+you have some libraries under /usr/local/ and others under
+/usr/you, then you have to include both, namely
+
+ sh Configure -de \
+ -Dlocincpth="/usr/you/include /usr/local/include" \
+ -Dloclibpth="/usr/you/lib /usr/local/lib"
+
+=back
+
+=head2 Building DB, NDBM, and ODBM interfaces with Berkeley DB 3
+
+Perl interface for DB3 is part of Berkeley DB, but if you want to
+compile standard Perl DB/ODBM/NDBM interfaces, you must follow
+following instructions.
+
+Berkeley DB3 from Sleepycat Software is by default installed without
+DB1 compatibility code (needed for DB_File interface) and without
+links to compatibility files. So if you want to use packages written
+for DB/ODBM/NDBM interfaces, you need to configure DB3 with
+--enable-compat185 (and optionally with --enable-dump185) and create
+additional references (suppose you are installing DB3 with
+--prefix=/usr):
+
+ ln -s libdb-3.so /usr/lib/libdbm.so
+ ln -s libdb-3.so /usr/lib/libndbm.so
+ echo '#define DB_DBM_HSEARCH 1' >dbm.h
+ echo '#include ' >>dbm.h
+ install -m 0644 dbm.h /usr/include/dbm.h
+ install -m 0644 dbm.h /usr/include/ndbm.h
+
+Optionally, if you have compiled with --enable-compat185 (not needed
+for ODBM/NDBM):
+
+ ln -s libdb-3.so /usr/lib/libdb1.so
+ ln -s libdb-3.so /usr/lib/libdb.so
+
+ODBM emulation seems not to be perfect, but is quite usable,
+using DB 3.1.17:
+
+ lib/odbm.............FAILED at test 9
+ Failed 1/64 tests, 98.44% okay
=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
@@ -549,24 +1217,25 @@ 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 &
-flags) you can type C<&-d> at the next Configure prompt and Configure
+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.
+=item Hint files
The perl distribution includes a number of system-specific hints files
in the hints/ directory. If one of them matches your system, Configure
will offer to use that hint file.
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 F for an
-extensive example.
+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.
=item *** WHOA THERE!!! ***
@@ -591,96 +1260,187 @@ 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 library and will issue a message:
+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 I want to keep the previous value, so you
+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 I re-use your old config.sh. Simply remove it or
+probably not re-use your old config.sh. Simply remove it or
rename it, e.g. mv config.sh config.sh.old. Then rerun Configure
with the options you want to use.
-This is a common source of problems. If you change from B to
-B, you should almost always remove your old config.sh.
+This is a common source of problems. If you change from cc to
+gcc, you should almost always remove your old config.sh.
=item Propagating your changes to config.sh
-If you make any changes to F, you should propagate
-them to all the .SH files by running B. You will
-then have to rebuild by running
+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
+=item config.over and config.arch
+
+You can also supply a shell script config.over to over-ride
+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.
-You can also supply a shell script config.over to over-ride 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. See the section on
-L<"Changing the installation directory"> for an example.
+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 F.
-F builds F by running the F script.
-The values for the variables are taken from F.
+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 F directly. Beware,
-though, that the next time you run B, your changes will be
+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 F. For instance, to turn off the
-optimizer on F, find the line in the switch structure for
-F and put the command C before the C<;;>. You
-can also edit F directly, but beware that your changes will be
-lost the next time you run B.
+line, they can be made in cflags.SH. For instance, to turn off the
+optimizer on toke.c, find the line in the switch structure for
+toke.c and put the command optimize='-g' before the ;; . You
+can also edit cflags directly, but beware that your changes will be
+lost the next time you run Configure.
-To change the C flags for all the files, edit F
-and change either C<$ccflags> or C<$optimize>,
-and then re-run B.
+To explore various ways of changing ccflags from within a hint file,
+see the file hints/README.hints.
-=item No sh.
+To change the C flags for all the files, edit config.sh and change either
+$ccflags or $optimize, and then re-run
-If you don't have sh, you'll have to copy the sample file config_H to
-config.h and edit the config.h to reflect your system's peculiarities.
+ 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 Digital UNIX/Tru64 UNIX and BIN_SH
+
+In Digital UNIX/Tru64 UNIX, Configure might abort with
+
+Build a threading Perl? [n]
+Configure[2437]: Syntax error at line 1 : `config.sh' is not expected.
+
+This indicates that Configure is being run with a broken Korn shell
+(even though you think you are using a Bourne shell by using
+"sh Configure" or "./Configure"). The Korn shell bug has been reported
+to Compaq as of February 1999 but in the meanwhile, the reason ksh is
+being used is that you have the environment variable BIN_SH set to
+'xpg4'. This causes /bin/sh to delegate its duties to /bin/posix/sh
+(a ksh). Unset the environment variable and rerun Configure.
+
+=item HP-UX 11, pthreads, and libgdbm
+
+If you are running Configure with -Dusethreads in HP-UX 11, be warned
+that POSIX threads and libgdbm (the GNU dbm library) compiled before
+HP-UX 11 do not mix. This will cause a basic test run by Configure to
+fail
+
+Pthread internal error: message: __libc_reinit() failed, file: ../pthreads/pthread.c, line: 1096
+Return Pointer is 0xc082bf33
+sh: 5345 Quit(coredump)
+
+and Configure will give up. The cure is to recompile and install
+libgdbm under HP-UX 11.
+
=item Porting information
-Specific information for the OS/2, Plan9, and VMS ports are in the
-corresponing subdirectories. Additional information, including
-a glossary of all those config.sh variables, is in the Porting
-subdirectory.
+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. Especially Porting/Glossary should come in handy.
Ports for other systems may also be available. You should check out
-L<"http://www.perl.com/CPAN/ports"> for current information on ports to
+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 Porting/patching.pod.
+Study also how other non-UNIX ports have solved problems.
+
=back
+=head1 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="Compress::Zlib Bundle::LWP DBI"
+
+or answer first 'y' to the question 'Install any extra modules?' and
+then answer "Compress::Zlib Bundle::LWP DBI" to the 'Extras?' question.
+The module or the bundle names are as for the CPAN module 'install' command.
+
+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 zlib.h header and the libz
+library installed for the Compress::Zlib, or 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.
+
+=head1 suidperl
+
+suidperl is an optional component, which is built or installed by default.
+From perlfaq1:
+
+ On some systems, setuid and setgid scripts (scripts written
+ in the C shell, Bourne shell, or Perl, for example, with the
+ set user or group ID permissions enabled) are insecure due to
+ a race condition in the kernel. For those systems, Perl versions
+ 5 and 4 attempt to work around this vulnerability with an optional
+ component, a special program named suidperl, also known as sperl.
+ This program attempts to emulate the set-user-ID and set-group-ID
+ features of the kernel.
+
+Because of the buggy history of suidperl, and the difficulty
+of properly security auditing as large and complex piece of
+software as Perl, we cannot recommend using suidperl and the feature
+should be considered deprecated.
+Instead use for example 'sudo': http://www.courtesan.com/sudo/
+
=head1 make depend
-This will look for all the includes.
-The output is stored in F. The only difference between
-F and F is the dependencies at the bottom of
-F. If you have to make any changes, you should edit
-F, not F since the Unix B command reads
-F 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.)
+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.
@@ -689,104 +1449,78 @@ explicitly above.
This will attempt to make perl in the current directory.
+=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, you can
-send a message to either the comp.lang.perl.misc newsgroup or to
-perlbug@perl.com with an accurate description of your problem.
-Please include the I