Each of these is explained in further detail below.
-B<NOTE>: starting from the release 5.6.0 Perl will use a version
-scheme where even-numbered subreleases (like 5.6) are stable
+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
unstable development releases. Development releases should not be
used in production environments. Fixes and new features are first
themselves to be worthy will they be migrated to the maintenance
releases.
-The above commands will install Perl to /usr/local or /opt, depending
-on the platform. If that's not okay with you, use
+The above commands will install Perl to /usr/local (or some other
+platform-specific directory -- see the appropriate file in hints/.)
+If that's not okay with you, use
rm -f config.sh Policy.sh
sh Configure
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
+similar, you may be on a case-insensitive filesystems such as Mac's HFS+,
+and you should say "make install-all". (This confusion is brought to you
by the Perl distribution having a file called INSTALL.)
If you have problems, corrections, or questions, please see
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.
+system. (Unixware users should use the svr4.sh hint file.)
+Additional information is in the Porting/ directory.
=head1 WARNING: This version requires an extra step to build old extensions.
5.005_53 and later releases do not export unadorned
-global symbols anymore. This means you may need to build older
-extensions that have not been updated for the new naming convention
+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
sh Configure -Accflags=-DPERL_POLLUTE
-pod/perldelta.pod contains more details about this.
+pod/perl56delta.pod contains more details about this.
-=head1 WARNING: This version may not be binary compatible with Perl 5.005.
+=head1 WARNING: This version is not binary compatible with releases of
+Perl prior to 5.8.0.
-Using the default Configure options for building perl should get you
-a perl that will be binary compatible with the 5.005 release.
-
-However, if you run Configure with any custom options, such as
--Dusethreads, -Dusemultiplicity, -Dusemymalloc, -Ubincompat5005 etc.,
-the resulting perl will not be binary compatible. Under these
-circumstances, if you have dynamically loaded extensions that were
-built under perl 5.005, you will need to rebuild and reinstall all
-those extensions to use them with 5.6.
+If you have built extensions (i.e. modules that include C code)
+using an earlier version of Perl, you will need to rebuild and reinstall
+those extensions.
Pure perl modules without XS or C code should continue to work fine
without reinstallation. See the discussions below on
L<"Coexistence with earlier versions of perl5"> and
-L<"Upgrading from 5.005 to 5.6"> for more details.
+L<"Upgrading from 5.005 or 5.6 to 5.8.0"> 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 pod/perl500Xdelta.pod) for a description of
+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
can tell F<Configure> 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:
+If do not have an ANSI-capable compiler there are a couple of avenues
+open to you:
=over 4
distribution (for example, F<README.hpux>), 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
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.
=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.
+also has several convenient options which are 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
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.
+architectures. You can do this (if your file system supports symbolic
+links) by
-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 ...
sh Configure -des
-Note: for development releases (odd subreleases, like 5.7, as opposed
-to maintenance releases which have even subreleases, like 5.6)
+Note: for development releases (odd subreleases, like 5.9, as opposed
+to maintenance releases which have even subreleases, like 5.6 and 5.8)
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
for a listing.
-Cross compiling and compiling in a different directory are not supported.
-
(The file is called configure.gnu to avoid problems on systems
that would not distinguish the files "Configure" and "configure".)
+See L<Cross-compilation> below for information on cross-compiling.
+
=head2 Installation Directories
The installation directories can all be changed by answering the
appropriate questions in Configure. For convenience, all the
installation questions are near the beginning of Configure.
-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.
+Do not include trailing slashes on directory names.
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.
+the defaults from then on. Alternatively, you can
+
+ grep '^install' config.sh
+
+after Configure has run to verify the installation paths.
The defaults are intended to be reasonable and sensible for most
people building from sources. Those who build and distribute binary
=item Directories for the perl distribution
-By default, Configure will use the following directories for 5.6.0.
+By default, Configure will use the following directories for 5.8.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,
+5.8.0 or 5.8.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.
By default, ExtUtils::MakeMaker will install architecture-independent
modules into $sitelib and architecture-dependent modules into $sitearch.
-NOTE: As of 5.6.0, ExtUtils::MakeMaker will use $sitelib and $sitearch,
-but will not use the other site-specific directories. Volunteers to
-fix this are needed.
-
=item Directories for vendor-supplied add-on files
Lastly, if you are building a binary distribution of perl for
/usr hierarchy, while the directories reserved for the end-user are in
the /usr/local hierarchy.
-NOTE: As of 5.6.0, ExtUtils::MakeMaker does not use these directories.
-Volunteers to fix this are needed.
-
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
Perl will search these directories (including architecture and
version-specific subdirectories) for add-on modules and extensions.
+For example, if you have a bundle of perl libraries from a previous
+installation, perhaps in a strange place:
+
+ Configure -Dotherlibdirs=/usr/lib/perl5/site_perl/5.6.1
+
=item APPLLIB_EXP
There is one other way of adding paths to @INC at perl build time, and
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
+ sh Configure -Dman3dir=/usr/local/lib/perl5/5.8.0/man/man3
Some users also prefer to use a .3pm suffix. You can do that with
=item HTML pages
-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.
+Currently, the standard perl installation does not do anything with
+HTML documentation, but that may change in the future. Further, some
+add-on modules may wish to install HTML documents. The html Configure
+variables listed above are provided if you wish to specify where such
+documents should be placed. The default is "none", but will likely
+eventually change to something useful based on user feedback.
=back
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.6.0 are
+-Dprefix=/opt/perl, then the default library directories for 5.8.0 are
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
+ $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
=head2 Changing the installation directory
to contain any valid shell commands. It will be run just after the
platform-specific hints files.
-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.
-
=head2 Configure-time Options
There are several different ways to Configure and build perl for your
=head2 Threads
-On some platforms, perl5.005 and later can be compiled with
-experimental support for threads. To enable this, read the file
-README.threads, and then try:
+On some platforms, perl can be compiled with
+support for threads. To enable this, run
sh Configure -Dusethreads
By default, Configure selects ithreads if -Dusethreads is specified.
-However, you can select the old 5005threads behavior
+(You need to also use the PerlIO layer, explained later, if you decide
+to use ithreads, to guarantee the good interworking of threads and I/O.)
+
+However, if you wish, you can select the unsupported old 5005threads behavior
sh Configure -Dusethreads -Duse5005threads
and the 'Thread' module offers an interface to both 5005threads and
ithreads (whichever has been configured).
+When building threaded for certain library calls like the getgr*() and
+the getpw*() there is a dynamically sized result buffer: the buffer
+starts small but Perl will keep growing the buffer until the result fits.
+To get a fixed upper limit you will have to recompile Perl with
+PERL_REENTRANT_MAXSIZE defined to be the number of bytes you want.
+One way to do this is to run Configure with
+C<-Accflags=-DPERL_REENTRANT_MAXSIZE=65536>
+
=head2 Large file support.
-Since Perl 5.6.0 Perl has supported large files (files larger than
+Since Perl 5.6.0, Perl has supported large files (files larger than
2 gigabytes), and in many common platforms like Linux or Solaris this
support is on by default.
This is both good and bad. It is good in that you can use large files,
-seek(), stat(), and -s them. It is bad if you are interfacing Perl
-using some extension, also the components you are connecting to must
+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
=head2 Selecting File IO mechanisms
-Previous versions of perl used the standard IO mechanisms as defined in
-stdio.h. Versions 5.003_02 and later of perl allowed alternate IO
-mechanisms via a "PerlIO" abstraction, but the stdio mechanism is still
-the default and is the only supported mechanism.
+Executive summary: in Perl 5.8, you should use the default "PerlIO"
+as the IO mechanism unless you have a good reason not to.
-Starting from Perl 5.8 the default mechanism is to use the PerlIO
+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 disabled either on the Configure
-command line with
+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
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 else than LD_LIBRARY_PATH for you, see above.)
+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),
There is also an potential problem with the shared perl library if you
want to have more than one "flavor" of the same version of perl (e.g.
with and without -DDEBUGGING). For example, suppose you build and
-install a standard Perl 5.004 with a shared library. Then, suppose you
-try to build Perl 5.004 with -DDEBUGGING enabled, but everything else
+install a standard Perl 5.8.0 with a shared library. Then, suppose you
+try to build Perl 5.8.0 with -DDEBUGGING enabled, but everything else
the same, including all the installation directories. How can you
ensure that your newly built perl will link with your newly built
-libperl.so.4 rather with the installed libperl.so.4? The answer is
+libperl.so.8 rather with the installed libperl.so.8? The answer is
that you might not be able to. The installation directory is encoded
in the perl binary with the LD_RUN_PATH environment variable (or
equivalent ld command-line option). On Solaris, you can override that
-with LD_LIBRARY_PATH; on Linux you can't. On Digital Unix, you can
-override LD_LIBRARY_PATH by setting the _RLD_ROOT environment variable
-to point to the perl build directory.
+with LD_LIBRARY_PATH; on Linux, you can only override at runtime via
+LD_PRELOAD, specifying the exact filename you wish to be used; and on
+Digital Unix, you can override LD_LIBRARY_PATH by setting the
+_RLD_ROOT environment variable to point to the perl build directory.
The only reliable answer is that you should specify a different
directory for the architecture-dependent library for your -DDEBUGGING
=item -DPERL_POLLUTE_MALLOC
-NOTE: This flag is enabled automatically on some platforms if you
-asked for binary compatibility with version 5.005, or if you just
-run Configure to accept all the defaults on those platforms. You
-can refuse the automatic binary compatibility flags wholesale by
-running:
-
- sh Configure -Ubincompat5005
+NOTE: This flag is enabled automatically on some platforms if you just
+run Configure to accept all the defaults on those platforms.
-or by answering 'n' at the appropriate prompt.
+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.
-Perl's malloc family of functions are called Perl_malloc(),
-Perl_realloc(), Perl_calloc() and Perl_mfree(). When this flag is
-not enabled, the names do not clash with the system versions of
-these functions.
-
-If enabled, Perl's malloc family of functions will have the same
-names as the system versions. This may be sometimes required when you
-have libraries that like to free() data that may have been allocated
-by Perl_malloc() and vice versa.
+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
You'll probably also have to extensively modify the extension building
mechanism.
-=item Environment variable clashes
-
-Configure uses a CONFIG variable that is reported to cause trouble on
-ReliantUnix 5.44. If your system sets this variable, you can try
-unsetting it before you run Configure. Configure should eventually
-be fixed to avoid polluting the namespace of the environment.
-
=item Digital UNIX/Tru64 UNIX and BIN_SH
In Digital UNIX/Tru64 UNIX, Configure might abort with
=item Porting information
-Specific information for the OS/2, Plan9, VMS and Win32 ports is in the
+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.
installed. It installs a /usr/local/include/arpa/inet.h that refers to
these symbols. Versions of BIND later than 8.1 do not install inet.h
in that location and avoid the errors. You should probably update to a
-newer version of BIND. If you can't, you can either link with the
-updated resolver library provided with BIND 8.1 or rename
-/usr/local/bin/arpa/inet.h during the Perl build and test process to
-avoid the problem.
+newer version of BIND (and remove the files the old one left behind).
+If you can't, you can either link with the updated resolver library provided
+with BIND 8.1 or rename /usr/local/bin/arpa/inet.h during the Perl build and
+test process to avoid the problem.
+
+=item *_r() prototype NOT found
+
+On a related note, if you see a bunch of complaints like the above about
+reentrant functions - specifically networking-related ones - being present
+but without prototypes available, check to see if BIND 8.1 (or possibly
+other BIND 8 versions) is (or has been) installed. They install
+header files such as netdb.h into places such as /usr/local/include (or into
+another directory as specified at build/install time), at least optionally.
+Remove them or put them in someplace that isn't in the C preprocessor's
+header file include search path (determined by -I options plus defaults,
+normally /usr/include).
=item #error "No DATAMODEL_NATIVE specified"
UTS may need one or more of -K or -g, and undef LSTAT.
FreeBSD can fail the lib/ipc_sysv.t test if SysV IPC has not been
-configured to the kernel. Perl tries to detect this, though, and
+configured in the kernel. Perl tries to detect this, though, and
you will get a message telling what to do.
-Machines with half-implemented dbm routines will need to #undef I_ODBM
-
HP-UX 11 Y2K patch "Y2K-1100 B.11.00.B0125 HP-UX Core OS Year 2000
Patch Bundle" has been reported to break the io/fs test #18 which
tests whether utime() can change timestamps. The Y2K patch seems to
break utime() so that over NFS the timestamps do not get changed
(on local filesystems utime() still works).
+Building Perl on a system that has also BIND (headers and libraries)
+installed may run into troubles because BIND installs its own netdb.h
+and socket.h, which may not agree with the operating system's ideas of
+the same files. Similarly, including -lbind may conflict with libc's
+view of the world. You may have to tweak -Dlocincpth and -Dloclibpth
+to avoid the BIND.
+
=back
=head2 Cross-compilation
./perl -I../lib ../ext/Socket/Socket.t
./perl -I../lib ../lib/less.t
-(For csh-like shells on UNIX, adjust appropriately for other platforms.)
+(For csh-like shells on UNIX; adjust appropriately for other platforms.)
You should also read the individual tests to see if there are any helpful
comments that apply to your system. You may also need to setup your
shared library path if you get errors like:
Several tests in the test suite check timing functions, such as
sleep(), and see if they return in a reasonable amount of time.
-If your system is quite busy and doesn't return quickly enough,
-these tests might fail. If possible, try running the tests again with
-the system under a lighter load. These tests include F<t/op/alarm.t>,
-F<ext/Time/HiRes/HiRes.t>, and F<lib/Benchmark.t>.
+If your system is quite busy and doesn't respond quickly enough,
+these tests might fail. If possible, try running the tests again
+with the system under a lighter load. These timing-sensitive
+and load-sensitive tests include F<t/op/alarm.t>,
+F<ext/Time/HiRes/HiRes.t>, F<lib/Benchmark.t>,
+F<lib/Memoize/t/expmod_t.t>, and F<lib/Memoize/t/speed.t>.
=item Out of memory
the user ids in the distribution package are used as-is. Some tar
programs do this.
-(2) If the directory the test are being run in is writable by group
-or by other (remember: with UNIX/POSIX semantics, write access to
+(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
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 the
+(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
+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.
make install PERLNAME=perl5 PERLNAME_VERBASE=perl
-This can be useful if you have to install perl as "perl5" (due to an
-ancient version in /usr/bin supplied by your vendor, eg). Without this
-the versioned binary would be called "perl55.005".
+This can be useful if you have to install perl as "perl5" (e.g. to
+avoid conflicts with an ancient version in /usr/bin supplied by your vendor).
+Without this the versioned binary would be called "perl55.005".
=head2 Installed files
=head1 Coexistence with earlier versions of perl5
+Perl 5.8 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
all of your add-on extensions. You can also safely leave the old version
top of the script with the particular version you want to run, e.g.
#!/usr/local/bin/perl5.00404.
-Most extensions will probably not need to be recompiled to use
-with a newer version of perl. Here is how it is supposed to work.
-(These examples assume you accept all the Configure defaults.)
+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
+being an exception). Here is how it is supposed to work. (These
+examples assume you accept all the Configure defaults.)
Suppose you already have version 5.005_03 installed. The directories
searched by 5.005_03 are
but will not interfere with the 5.005_03 version.
The last entry, /usr/local/lib/perl5/site_perl/, is there so that
-5.6.0 will look for 5.004-era pure perl modules.
+5.6.0 and above will look for 5.004-era pure perl modules.
-Lastly, suppose you now install version 5.6.1, which we'll assume is
-binary compatible with 5.6.0 and 5.005. The directories searched
-by 5.6.1 (if you don't change the Configure defaults) will be:
+Lastly, suppose you now install 5.8.0, which is not binary compatible
+with 5.6.0. The directories searched by 5.8.0 (if you don't change the
+Configure defaults) will be:
- /usr/local/lib/perl5/5.6.1/$archname
- /usr/local/lib/perl5/5.6.1
- /usr/local/lib/perl5/site_perl/5.6.1/$archname
- /usr/local/lib/perl5/site_perl/5.6.1
+ /usr/local/lib/perl5/5.8.0/$archname
+ /usr/local/lib/perl5/5.8.0
+ /usr/local/lib/perl5/site_perl/5.8.0/$archname
+ /usr/local/lib/perl5/site_perl/5.8.0
- /usr/local/lib/perl5/site_perl/5.6.0/$archname
/usr/local/lib/perl5/site_perl/5.6.0
- /usr/local/lib/perl5/site_perl/5.005/$archname
/usr/local/lib/perl5/site_perl/5.005
+
/usr/local/lib/perl5/site_perl/
+Note that the earlier $archname entries are now gone, but pure perl
+modules from earlier versions will still be found.
+
Assuming the users in your site are still actively using perl 5.6.0 and
-5.005 after you installed 5.6.1, you can continue to install add-on
-extensions using any of perl 5.6.1, 5.6.0, or 5.005. The installations
-of these different versions remain distinct, but remember that the newer
-versions of perl are automatically set up to search the site libraries of
-the older ones. This means that installing a new extension with 5.005
-will make it visible to all three versions. Later, if you install the
-same extension using, say, perl 5.6.1, it will override the 5.005-installed
-version, but only for perl 5.6.1.
+5.005 after you installed 5.8.0, you can continue to install add-on
+extensions using any of perl 5.8.0, 5.6.0, or 5.005. The installations
+of these different versions remain distinct, but remember that the
+newer versions of perl are automatically set up to search the
+compatible site libraries of the older ones. This means that
+installing a new XS extension with 5.005 will make it visible to both
+5.005 and 5.6.0, but not to 5.8.0. Installing a pure perl module with
+5.005 will make it visible to all three versions. Later, if you
+install the same extension using, say, perl 5.8.0, it will override the
+5.005-installed version, but only for perl 5.8.0.
This way, you can choose to share compatible extensions, but also upgrade
to a newer version of an extension that may be incompatible with earlier
scripts can still start with #!/usr/local/bin/perl.
Others might share a common directory for maintenance sub-versions
-(e.g. 5.004 for all 5.004_0x versions), but change directory with
+(e.g. 5.8 for all 5.8.x versions), but change directory with
each major version.
If you are installing a development subversion, you probably ought to
subversions may not have all the compatibility wrinkles ironed out
yet.
-=head2 Upgrading from 5.005 to 5.6.0
+=head2 Upgrading from 5.005 or 5.6 to 5.8.0
-Most extensions built and installed with versions of perl
-prior to 5.005_50 will not need to be recompiled to be used with
-5.6.0. If you find you do need to rebuild an extension with 5.6.0,
-you may safely do so without disturbing the 5.005 installation.
-(See L<"Coexistence with earlier versions of perl5"> above.)
+B<Perl 5.8.0 is binary incompatible with Perl 5.6.1, 5.6.0, 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
+installations. (See L<"Coexistence with earlier versions of perl5">
+above.)
See your installed copy of the perllocal.pod file for a (possibly
incomplete) list of locally installed modules. Note that you want
-perllocal.pod not perllocale.pod for installed module information.
+perllocal.pod, not perllocale.pod, for installed module information.
=head1 Coexistence with perl4
operating systems, or in really small filesystems).
Leaving out as many extensions as possible is an obvious way:
-especially the Encode with its big conversion tables consumes a lot of
-space. On the other hand, you cannot throw away everything, espcially
-the Fcntl module is pretty essential. If you need to do network
+Encode, with its big conversion tables, consumes a lot of
+space. On the other hand, you cannot throw away everything. The
+Fcntl module is pretty essential. If you need to do network
programming, you'll appreciate the Socket module, and so forth: it all
depends on what do you need to do.