B<NOTE>: starting from the release 5.6.0, Perl uses a version
scheme where even-numbered subreleases (like 5.6 and 5.8) are stable
-maintenance releases and odd-numbered subreleases (like 5.7) are
+maintenance releases and odd-numbered subreleases (like 5.7 and 5.9) are
unstable development releases. Development releases should not be
used in production environments. Fixes and new features are first
carefully tested in development releases and only if they prove
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.)
+system. (Unixware users should use the svr4.sh or the svr5.sh hint file.)
Additional information is in the Porting/ directory.
=head1 WARNING: This version requires an extra step to build old extensions.
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.
+Perl prior to 5.9.0.
If you have built extensions (i.e. modules that include C code)
using an earlier version of Perl, you will need to rebuild and reinstall
=head1 Space Requirements
-The complete perl5 source tree takes up about 50 MB of disk space.
+The complete perl5 source tree takes up about 60 MB of disk space.
After completing make, it takes up roughly 100 MB, though the actual
total is likely to be quite system-dependent. The installation
directories need something on the order of 45 MB, though again that
-value is system-dependent.
+value is system-dependent. A perl build with debug symbols and
+-DDEBUGGING will require something on the order of 10 MB extra.
=head1 Start with a Fresh Distribution
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.
+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
-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
+ perl -V:config_args
- Configure -Uinstallusrbinperl
+(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.)
-or by answering 'no' to the appropriate Configure prompt.
+By default, Configure will not try to link /usr/bin/perl to
+the current version of perl. You can turn on that behavior by running
+
+ Configure -Dinstallusrbinperl
+
+or by answering 'yes' to the appropriate Configure prompt.
+(Note that before perl 5.8.1, the default behavior was to create
+or overwrite /usr/bin/perl even if it already existed.)
In any case, system administrators are strongly encouraged to
put (symlinks to) perl and its accompanying utilities, such as perldoc,
=item Directories for the perl distribution
-By default, Configure will use the following directories for 5.8.0.
+By default, Configure will use the following directories for 5.9.0.
$version is the full perl version number, including subversion, e.g.
-5.8.0 or 5.8.1, and $archname is a string like sun4-sunos,
+5.9.0 or 5.9.1, and $archname is a string like sun4-sunos,
determined by Configure. The full definitions of all Configure
variables are in the file Porting/Glossary.
$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)
+ $siteman1dir $siteprefix/man/man1
+ $siteman3dir $siteprefix/man/man3
+ $sitehtml1dir (none)
+ $sitehtml3dir (none)
By default, ExtUtils::MakeMaker will install architecture-independent
modules into $sitelib and architecture-dependent modules into $sitearch.
$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)
+ $vendorman1dir $vendorprefix/man/man1
+ $vendorman3dir $vendorprefix/man/man3
+ $vendorhtml1dir (none)
+ $vendorhtml3dir (none)
These are normally empty, but may be set as needed. For example,
a vendor might choose the following settings:
$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
+ $siteman1dir /usr/local/man/man1
+ $siteman3dir /usr/local/man/man3
$vendorbin /usr/bin
$vendorscript /usr/bin
$vendorlib /usr/lib/perl5/vendor_perl/$version
$vendorarch /usr/lib/perl5/vendor_perl/$version/$archname
- $vendorman1 /usr/man/man1
- $vendorman3 /usr/man/man3
+ $vendorman1dir /usr/man/man1
+ $vendorman3dir /usr/man/man3
Note how in this example, the vendor-supplied directories are in the
/usr hierarchy, while the directories reserved for the end-user are in
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.6.1
+ Configure -Dotherlibdirs=/usr/lib/perl5/site_perl/5.8.1
=item APPLLIB_EXP
You can continue to use the old default from the command line with
- sh Configure -Dman3dir=/usr/local/lib/perl5/5.8.0/man/man3
+ sh Configure -Dman3dir=/usr/local/lib/perl5/5.9.0/man/man3
Some users also prefer to use a .3pm suffix. You can do that with
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.8.0 are
+-Dprefix=/opt/perl, then the default library directories for 5.9.0 are
Configure variable Default value
- $privlib /opt/perl/lib/5.8.0
- $archlib /opt/perl/lib/5.8.0/$archname
- $sitelib /opt/perl/lib/site_perl/5.8.0
- $sitearch /opt/perl/lib/site_perl/5.8.0/$archname
+ $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
cd /opt/perl # Or wherever you specified as $prefix
tar xvf perl5-archive.tar
+Alternatively, the DESTDIR variable is honored during C<make install>.
+The DESTDIR is automatically prepended to all the installation paths
+(and there is no need to edit anything). With DESTDIR, the above
+example can we written as:
+
+ sh Configure -Dprefix=/opt/perl -des
+ make
+ make test
+ make install DESTDIR=/tmp/perl5
+ cd /tmp/perl5/opt/perl
+ tar cvf /tmp/perl5-archive.tar .
+
=head2 Site-wide Policy settings
After Configure runs, it stores a number of common site-wide "policy"
=head2 Selecting File IO mechanisms
-Executive summary: in Perl 5.8, you should use the default "PerlIO"
+Executive summary: as of Perl 5.8, you should use the default "PerlIO"
as the IO mechanism unless you have a good reason not to.
In more detail: previous versions of perl used the standard IO
_exit vs. exit. If you have this problem, the fix is to go back to
your sfio sources and correct iffe's guess about atexit.
+=head2 Algorithmic Complexity Attacks on Hashes
+
+In Perls 5.8.0 and earlier it was easy to create degenerate hashes.
+Processing such hashes would consume large amounts of CPU time,
+enabling a "Denial of Service" attack against Perl. Such hashes may be
+a problem for example for mod_perl sites, sites with Perl CGI scripts
+and web services, that process data originating from external sources.
+
+In Perl 5.8.1 a security feature was introduced to make it harder
+to create such degenerate hashes.
+
+Because of this feature the keys(), values(), and each() functions may
+return the hash elements in different order between different runs of
+Perl even with the same data. One can still revert to the old
+repeatable order by setting the environment variable PERL_HASH_SEED,
+see L<perlrun/PERL_HASH_SEED>. Another option is to add
+-DUSE_HASH_SEED_EXPLICIT to the compilation flags (for example by
+using C<Configure -Accflags=-DUSE_HAS_SEED_EXPLICIT>), in which case
+one has to explicitly set the PERL_HASH_SEED environment variable to
+enable the security feature, or by adding -DNO_HASH_SEED to the compilation
+flags to completely disable the randomisation feature.
+
+B<Perl has never guaranteed any ordering of the hash keys>, and the
+ordering has already changed several times during the lifetime of
+Perl 5. Also, the ordering of hash keys has always been, and
+continues to be, affected by the insertion order.
+
+Note that because of this randomisation for example the Data::Dumper
+results will be different between different runs of Perl since
+Data::Dumper by default dumps hashes "unordered". The use of the
+Data::Dumper C<Sortkeys> option is recommended.
+
=head2 SOCKS
Perl can be configured to be 'socksified', that is, to use the SOCKS
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 by changing all the *archlib*
-variables in config.sh to point to your new architecture-dependent library.
+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.
=head2 Malloc Issues
Devel::Peek::mstat() function. You cannot enable this unless you are
using Perl's malloc, so a typical Configure command would be
- sh Configure -DPERL_DEBUGGING_MSTATS -Dusemymalloc='y'
+ sh Configure -Accflags=-DPERL_DEBUGGING_MSTATS -Dusemymalloc='y'
to enable this option.
it's convenient to have both.
If you are using a shared libperl, see the warnings about multiple
-versions of perl under L<Building a shared libperl.so Perl library>.
+versions of perl under L<Building a shared Perl library>.
=head2 Extensions
you can build and install extensions just fine even if you don't have
dynamic loading. See lib/ExtUtils/MakeMaker.pm for more details.)
+If you have dynamic loading, another way of specifying extra modules
+is described in L<"Adding extra modules to the build"> below.
+
You can learn more about each of the supplied extensions by consulting the
documentation in the individual .pm modules, located under the
ext/ subdirectory.
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.
+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,
This will attempt to make perl in the current directory.
+=head2 Expected errors
+
+These errors 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.
=item invalid token: ##
You are using a non-ANSI-compliant C compiler. See L<WARNING: This
-version requires a compiler that supports ANSI C>.
+version requires a compiler that supports ANSI C.>
=item Miscellaneous
functionality.
NOTE: Perl is routinely built using cross-compilation
- in the EPOC environment but the solutions from there
- can't directly be used elsewhere.
-
-The one environment where cross-compilation has successfully been used
-as of this writing is the Compaq iPAQ running ARM Linux. The build
-host was Intel Linux, the networking setup was PPP + SSH. The exact
-setup details are beyond the scope of this document, see
-http://www.handhelds.org/ for more information.
+ in the EPOC environment, in the WinCE, and in the OpenZaurus
+ project, but all those use something slightly different setup
+ than what described here. For the WinCE setup, read the
+ wince/README.compile. For the OpenZaurus setup, read the
+ Cross/README.
+
+The one environment where this cross-compilation setup has
+successfully been used as of this writing is the Compaq iPAQ running
+ARM Linux. The build host was Intel Linux, the networking setup was
+PPP + SSH. The exact setup details are beyond the scope of this
+document, see http://www.handhelds.org/ for more information.
To run Configure in cross-compilation mode the basic switch is
C<-Dusecrosscompile>.
tries to exercise the regular expression subsystem quite thoroughly,
and may well be far more demanding than your normal usage.
-=item Test failures from lib/ftmp-security saying "system possibly insecure"
-
-Firstly, test failures from the ftmp-security are not necessarily
-serious or indicative of a real security threat. That being said,
-they bear investigating.
-
-The tests may fail for the following reasons. Note that each of the
-tests is run both in the building directory and the temporary
-directory, as returned by File::Spec->tmpdir().
-
-(1) If the directory the tests are being run is owned by somebody else
-than the user running the tests, or root (uid 0). This failure can
-happen if the Perl source code distribution is unpacked in 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 (remember: with UNIX/POSIX semantics, write access to
-a directory means the right to add/remove files in that directory),
-and there is no sticky bit set in the directory. 'Sticky bit' is
-a feature used in some UNIXes to give extra protection to files: if
-the bit is on a directory, no one but the owner (or the root) can remove
-that file even if the permissions of the directory would allow file
-removal by others. This failure can happen if the permissions in the
-directory simply are a bit too liberal for the tests' liking. This
-may or may not be a real problem: it depends on the permissions policy
-used on this particular directory/project/system/site. 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.
+=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).
+(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.
+about the various security aspects of temporary files.
=back
=head1 Coexistence with earlier versions of perl5
-Perl 5.8 is not binary compatible with earlier versions of Perl.
+Perl 5.9 is not binary compatible with earlier versions of Perl.
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.004_04) to another similar version (e.g. 5.004_05) without re-compiling
+5.8.0) to another similar version (e.g. 5.8.2) without re-compiling
all of your add-on extensions. You can also safely leave the old version
around in case the new version causes you problems for some reason.
For example, if you want to be sure that your script continues to run
-with 5.004_04, simply replace the '#!/usr/local/bin/perl' line at the
+with 5.8.2, simply replace the '#!/usr/local/bin/perl' line at the
top of the script with the particular version you want to run, e.g.
-#!/usr/local/bin/perl5.00404.
+#!/usr/local/bin/perl5.8.2.
Usually, most extensions will probably not need to be recompiled to
use with a newer version of Perl (the Perl 5.6 to Perl 5.8 transition
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.004
+ sh Configure -Dprefix=/opt/perl5.8.2
-and adding /opt/perl5.004/bin to the shell PATH variable. Such users
+and adding /opt/perl5.8.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.
=head2 Upgrading from 5.005 or 5.6 to 5.8.0
-B<Perl 5.8.0 is binary incompatible with Perl 5.6.1, 5.6.0, 5.005,
+B<Perl 5.9.0 is binary incompatible with Perl 5.8.x, Perl 5.6.x, 5.005,
and any earlier Perl release.> Perl modules having binary parts
(meaning that a C compiler is used) will have to be recompiled to be
-used with 5.8.0. If you find you do need to rebuild an extension with
-5.8.0, you may safely do so without disturbing the 5.005 or 5.6.0
+used with 5.9.0. If you find you do need to rebuild an extension with
+5.9.0, you may safely do so without disturbing the older
installations. (See L<"Coexistence with earlier versions of perl5">
above.)
projects / p5sagit/p5-mst-13.2.git / blobdiff