the most important issues are listed below, but you should refer
to pod/perldelta.pod for more detailed information.
-B<WARNING:> This version is not binary compatible with prior releases of Perl.
-If you have built extensions (i.e. modules that include C code)
+B<WARNING:> This version is not binary compatible with earlier versions
+of Perl. 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.
The default is to compile without thread support.
-Perl used to have two different internal threads implementations. The current
-model (available internally since 5.6, and as a user-level module since 5.8) is
-called interpreter-based implementation (ithreads), with one interpreter per
-thread, and explicit sharing of data. The (deprecated) 5.005 version
-(5005threads) was removed for release 5.10.
+Perl used to have two different internal threads implementations. The
+current model (available internally since 5.6, and as a user-level module
+since 5.8) is called interpreter-based implementation (ithreads), with
+one interpreter per thread, and explicit sharing of data. The (deprecated)
+5.005 version (5005threads) was removed for release 5.10.
The 'threads' module is for use with the ithreads implementation. The
-'Thread' module emulates the old 5005threads interface on top of the current
-ithreads model.
+'Thread' module emulates the old 5005threads interface on top of the
+current ithreads model.
When using threads, perl uses a dynamically-sized buffer for some of
the thread-safe library calls, such as those in the getpw*() family.
support is on by default.
This is both good and bad. It is good in that you can use large files,
-seek(), stat(), and -s them. It is bad in that if you are interfacing Perl
-using some extension, the components you are connecting to must also
+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.
(that is, Perl's numbers). Use Configure -Duselongdouble to enable
this support (if it is available).
+Note that the exact format and range of long doubles varies:
+the most common is the x86 80-bit (64 bits of mantissa) format,
+but there are others, with different mantissa and exponent ranges.
+
=head3 "more bits"
You can "Configure -Dusemorebits" to turn on both the 64-bit support
and the long double support.
+=head3 quadmath
+
+One option for more precision is that gcc 4.6 and later have a library
+called quadmath, which implements the IEEE 754 quadruple precision
+(128-bit, 113 bits of mantissa) floating point numbers. The library
+works at least on x86 and ia64 platforms. It may be part of your gcc
+installation, or you may need to install it separately.
+
+With "Configure -Dusequadmath" you can try enabling its use, but note
+the compiler dependency, you may need to also add "-Dcc=...".
+At C level the type is called C<__float128> (note, not "long double"),
+but Perl source knows it as NV. (This is not "long doubles".)
+
=head3 Algorithmic Complexity Attacks on Hashes
Perl 5.18 reworked the measures used to secure its hash function
You can override various aspects of this feature by defining various
symbols during configure. An example might be:
- Configure -Accflags=-DPERL_HASH_FUNC_SIPHASH
+ sh Configure -Accflags=-DPERL_HASH_FUNC_SIPHASH
B<Unless stated otherwise these options are considered experimental or
insecure and are not recommended for production use.>
hashes "unordered". The use of the Data::Dumper C<Sortkeys> option is
recommended.
-See L<perlrun/PERL_HASH_SEED> and L<perlrun/PERL_PERTURB_KEYS> for details on
-the environment variables, and L<perlsec/Algorithmic Complexity Attacks> for
-further security details.
+See L<perlrun/PERL_HASH_SEED> and L<perlrun/PERL_PERTURB_KEYS> for
+details on the environment variables, and L<perlsec/Algorithmic
+Complexity Attacks> for further security details.
+
+The C<PERL_HASH_SEED> and PERL_PERTURB_KEYS> environment variables can
+be disabled by building configuring perl with
+C<-Accflags=-DNO_PERL_HASH_ENV>.
+
+The C<PERL_HASH_SEED_DEBUG> environment variable can be disabled by
+configuring perl with C<-Accflags=-DNO_PERL_HASH_SEED_DEBUG>.
=head3 SOCKS
=head3 Environment access
-Perl often needs to write to the program's environment, such as when C<%ENV>
-is assigned to. Many implementations of the C library function C<putenv()>
-leak memory, so where possible perl will manipulate the environment directly
-to avoid these leaks. The default is now to perform direct manipulation
-whenever perl is running as a stand alone interpreter, and to call the safe
-but potentially leaky C<putenv()> function when the perl interpreter is
-embedded in another application. You can force perl to always use C<putenv()>
-by compiling with C<-Accflags="-DPERL_USE_SAFE_PUTENV">, see section
-L</"Altering Configure variables for C compiler switches etc.">.
-You can force an embedded perl to use direct manipulation by setting
-C<PL_use_safe_putenv = 0;> after the C<perl_construct()> call.
+Perl often needs to write to the program's environment, such as when
+C<%ENV> is assigned to. Many implementations of the C library function
+C<putenv()> leak memory, so where possible perl will manipulate the
+environment directly to avoid these leaks. The default is now to perform
+direct manipulation whenever perl is running as a stand alone interpreter,
+and to call the safe but potentially leaky C<putenv()> function when the
+perl interpreter is embedded in another application. You can force perl
+to always use C<putenv()> by compiling with
+C<-Accflags="-DPERL_USE_SAFE_PUTENV">, see section L</"Altering Configure
+variables for C compiler switches etc.">. You can force an embedded perl
+to use direct manipulation by setting C<PL_use_safe_putenv = 0;> after
+the C<perl_construct()> call.
=head2 Installation Directories
=item Directories for the perl distribution
-By default, Configure will use the following directories for 5.21.3.
+By default, Configure will use the following directories for 5.26.0.
$version is the full perl version number, including subversion, e.g.
5.12.3, and $archname is a string like sun4-sunos,
determined by Configure. The full definitions of all Configure
$html1direxp (none)
$html3direxp (none)
-$prefixexp is generated from $prefix, with ~ expansion done to convert home
-directories into absolute paths. Similarly for the other variables listed. As
-file system calls do not do this, you should always reference the ...exp
-variables, to support users who build perl in their home directory.
+$prefixexp is generated from $prefix, with ~ expansion done to convert
+home directories into absolute paths. Similarly for the other variables
+listed. As file system calls do not do this, you should always reference
+the ...exp variables, to support users who build perl in their home
+directory.
Actually, Configure recognizes the SVR3-style
/usr/local/man/l_man/man1 directories, if present, and uses those
The entire installed library hierarchy is installed in locations with
version numbers, keeping the installations of different versions distinct.
-However, later installations of Perl can still be configured to search the
-installed libraries corresponding to compatible earlier versions.
-See L<"Coexistence with earlier versions of perl 5"> below for more details
-on how Perl can be made to search older version directories.
+However, later installations of Perl can still be configured to search
+the installed libraries corresponding to compatible earlier versions.
+See L<"Coexistence with earlier versions of perl 5"> below for more
+details on how Perl can be made to search older version directories.
Of course you may use these directories however you see fit. For
example, you may wish to use $siteprefix for site-specific files that
For example, if you have a bundle of perl libraries from a previous
installation, perhaps in a strange place:
- Configure -Dotherlibdirs=/usr/lib/perl5/site_perl/5.8.1
+ sh Configure -Dotherlibdirs=/usr/lib/perl5/site_perl/5.8.1
=item APPLLIB_EXP
directories ahead of those in APPLLIB_EXP by using any of the standard
run-time methods: $PERLLIB, $PERL5LIB, -I, use lib, etc.
+=item default_inc_excludes_dot
+
+Since version 5.26.0, default perl builds no longer includes C<'.'> as the
+last element of @INC. The old behaviour can restored using
+
+ sh Configure -Udefault_inc_excludes_dot
+
+Note that this is likely to make programs run under such a perl
+interpreter less secure.
+
=item usesitecustomize
Run-time customization of @INC can be enabled with:
being built. The list of perl versions found will be put in the Configure
variable inc_version_list.
-To disable this use of older perl modules, even completely valid pure perl
-modules, you can specify to not include the paths found:
+To disable this use of older perl modules, even completely valid pure
+perl modules, you can specify to not include the paths found:
sh Configure -Dinc_version_list=none ...
-If you do want to use modules from some previous perl versions, the variable
-must contain a space separated list of directories under the site_perl
-directory, and has to include architecture-dependent directories separately,
-eg.
+If you do want to use modules from some previous perl versions, the
+variable must contain a space separated list of directories under the
+site_perl directory, and has to include architecture-dependent
+directories separately, eg.
sh Configure -Dinc_version_list="5.16.0/x86_64-linux 5.16.0" ...
B<perl -d your_script>. If, however, you want to debug perl itself,
you probably want to have support for perl internal debugging code
(activated by adding -DDEBUGGING to ccflags), and/or support for the
-system debugger by adding -g to the optimisation flags. For that,
-use the parameter:
+system debugger by adding -g to the optimisation flags.
- sh Configure -DDEBUGGING
+A perl compiled with the DEBUGGING C preprocessor macro will support the
+C<-D> perl command-line switch, have assertions enabled, and have many
+extra checks compiled into the code; but will execute much more slowly
+(typically 2-3x) and the binary will be much larger (typically 2-3x).
-or
-
- sh Configure -DDEBUGGING=<mode>
-
-For a more eye appealing call, -DEBUGGING is defined to be an alias
-for -DDEBUGGING. For both, the -U calls are also supported, in order
-to be able to overrule the hints or Policy.sh settings.
+As a convenience, debugging code (-DDEBUGGING) and debugging symbols (-g)
+can be enabled jointly or separately using a Configure switch, also
+(somewhat confusingly) named -DDEBUGGING. For a more eye appealing call,
+-DEBUGGING is defined to be an alias for -DDEBUGGING. For both, the -U
+calls are also supported, in order to be able to overrule the hints or
+Policy.sh settings.
Here are the DEBUGGING modes:
=over 4
-=item -DDEBUGGING
+=item Configure -DDEBUGGING
-=item -DEBUGGING
+=item Configure -DEBUGGING
-=item -DEBUGGING=both
+=item Configure -DEBUGGING=both
Sets both -DDEBUGGING in the ccflags, and adds -g to optimize.
You can actually specify -g and -DDEBUGGING independently (see below),
but usually it's convenient to have both.
-=item -DEBUGGING=-g
+=item Configure -DEBUGGING=-g
-=item -Doptimize=-g
+=item Configure -Doptimize=-g
Adds -g to optimize, but does not set -DDEBUGGING.
(Note: Your system may actually require something like cc -g2.
Check your man pages for cc(1) and also any hint file for your system.)
-=item -DEBUGGING=none
+=item Configure -DEBUGGING=none
-=item -UDEBUGGING
+=item Configure -UDEBUGGING
Removes -g from optimize, and -DDEBUGGING from ccflags.
=head2 DTrace support
On platforms where DTrace is available, it may be enabled by
-using the -Dusedtrace option to Configure. DTrace probes are available for
-subroutine entry (sub-entry) and subroutine exit (sub-exit). Here's a
+using the -Dusedtrace option to Configure. DTrace probes are available
+for subroutine entry (sub-entry) and subroutine exit (sub-exit). Here's a
simple D script that uses them:
perl$target:::sub-entry, perl$target:::sub-return {
The version of BerkeleyDB distributed by Oracle installs in a
version-specific directory by default, typically something like
/usr/local/BerkeleyDB.4.7. To have Configure find that, you need to add
--I/usr/local/BerkeleyDB.4.7/include to cc flags, as in the previous example,
-and you will also have to take extra steps to help Configure find -ldb.
-Specifically, when Configure prompts you for library directories,
-add /usr/local/BerkeleyDB.4.7/lib to the list. Also, you will need to
-add appropriate linker flags to tell the runtime linker where to find the
-BerkeleyDB shared libraries.
+-I/usr/local/BerkeleyDB.4.7/include to cc flags, as in the previous
+example, and you will also have to take extra steps to help Configure
+find -ldb. Specifically, when Configure prompts you for library
+directories, add /usr/local/BerkeleyDB.4.7/lib to the list. Also, you
+will need to add appropriate linker flags to tell the runtime linker
+where to find the BerkeleyDB shared libraries.
It is possible to specify this from the command line (all on one
line):
If you are cross-compiling, or are using a compiler which has it's own
headers and libraries in a nonstandard location, and your compiler
-understands the C<--sysroot> option, you can use the C<-Dsysroot> option to
-specify the logical root directory under which all libraries and headers
-are searched for. This patch adjusts Configure to search under $sysroot, instead of /.
-
+understands the C<--sysroot> option, you can use the C<-Dsysroot> option
+to specify the logical root directory under which all libraries and
+headers are searched for. This patch adjusts Configure to search under
+$sysroot, instead of /.
+
--sysroot is added to ccflags and friends so that make in
ExtUtils::MakeMaker, and other extensions, will use it.
=item o
-How best to optimize for the platform, both in terms of binary size and/or
-speed, and for Perl feature support. Because of wide variations in the
-implementation of shared libraries and of threading, for example, Configure
-often needs hints in order to be able to use these features.
+How best to optimize for the platform, both in terms of binary size
+and/or speed, and for Perl feature support. Because of wide variations in
+the implementation of shared libraries and of threading, for example,
+Configure often needs hints in order to be able to use these features.
=back
not to, you should accept its offer.
Several of the hint files contain additional important information.
-If you have any problems, it is a good idea to read the relevant hint file
-for further information. See hints/solaris_2.sh for an extensive example.
-More information about writing good hints is in the hints/README.hints
-file, which also explains hint files known as callback-units.
+If you have any problems, it is a good idea to read the relevant hint
+file for further information. See hints/solaris_2.sh for an extensive
+example. More information about writing good hints is in the
+hints/README.hints file, which also explains hint files known as
+callback-units.
Note that any hint file is read before any Policy file, meaning that
Policy overrides hints -- see L</Site-wide Policy settings>.
=item WHOA THERE!!!
-If you are re-using an old config.sh, it's possible that Configure detects
-different values from the ones specified in this file. You will almost
-always want to keep the previous value, unless you have changed something
-on your system.
+If you are re-using an old config.sh, it's possible that Configure
+detects different values from the ones specified in this file. You will
+almost always want to keep the previous value, unless you have changed
+something on your system.
For example, suppose you have added libgdbm.a to your system
and you decide to reconfigure perl to use GDBM_File. When you run
toke) optimize='-g' ;;
*) ;;
-You should not edit the generated file cflags directly, as your changes will
-be lost the next time you run Configure, or if you edit config.sh.
+You should not edit the generated file cflags directly, as your changes
+will be lost the next time you run Configure, or if you edit config.sh.
To explore various ways of changing ccflags from within a hint file,
see the file hints/README.hints.
or answer first 'y' to the question 'Install any extra modules?' and
then answer "Bundle::LWP DBI" to the 'Extras?' question.
-The module or the bundle names are as for the CPAN module 'install' command.
-This will only work if those modules are to be built as dynamic
+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.
do not, using the extra modules option will die horribly.
Also notice that you yourself are responsible for satisfying any extra
-dependencies such as external headers or libraries BEFORE trying the build.
-For example: you will need to have the Foo database specific
+dependencies such as external headers or libraries BEFORE trying the
+build. For example: you will need to have the Foo database specific
headers and libraries installed for the DBD::Foo module. The Configure
process or the Perl build process will not help you with these.
them. I have some reports that some versions of IRIX hang while
running B<./miniperl configpm> with locales other than the C locale.
See the discussion under L<"make test"> below about locales and the
-whole L<perllocale/"LOCALE PROBLEMS"> section in the file pod/perllocale.pod.
-The latter is especially useful if you see something like this
+whole L<perllocale/"LOCALE PROBLEMS"> section in the file
+pod/perllocale.pod. The latter is especially useful if you see something
+like this
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
these symbols. Versions of BIND later than 8.1 do not install inet.h
in that location and avoid the errors. You should probably update to a
newer version of BIND (and remove the files the old one left behind).
-If you can't, you can either link with the updated resolver library provided
-with BIND 8.1 or rename /usr/local/bin/arpa/inet.h during the Perl build and
-test process to avoid the problem.
+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).
+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"
Some compilers will not compile or optimize the larger files (such as
toke.c) without some extra switches to use larger jump offsets or
allocate larger internal tables. You can customize the switches for
-each file in cflags.SH. It's okay to insert rules for specific files into
-makefile since a default rule only takes effect in the absence of a
+each file in cflags.SH. It's okay to insert rules for specific files
+into makefile since a default rule only takes effect in the absence of a
specific rule.
=item Missing dbmclose
1. Disable the use of ODBM_FILE
- Configure ... -Dnoextensions=ODBM_File
+ sh Configure ... -Dnoextensions=ODBM_File
2. Fix the header file, somewhat like this:
-extern int dbmclose __P((DBM *));
+extern int dbmclose __P((void));
-=item Note (probably harmless): No library found for -lsomething
+=item Warning (mostly harmless): No library found for -lsomething
If you see such a message during the building of an extension, but
the extension passes its tests anyway (see L<"make test"> below),
Makefile.PL goes looking for various libraries needed on various
systems; few systems will need all the possible libraries listed.
Most users will see warnings for the ones they don't have. The
-phrase 'probably harmless' is intended to reassure you that nothing
+phrase 'mostly harmless' is intended to reassure you that nothing
unusual is happening, and the build process is continuing.
On the other hand, if you are building GDBM_File and you get the
message
- Note (probably harmless): No library found for -lgdbm
+ Warning (mostly harmless): No library found for -lgdbm
then it's likely you're going to run into trouble somewhere along
the line, since it's hard to see how you can use the GDBM_File
=item Bad arg length for semctl, is XX, should be ZZZ
-If you get this error message from the ext/IPC/SysV/t/sem test, your System
-V IPC may be broken. The XX typically is 20, and that is what ZZZ
+If you get this error message from the F<cpan/IPC-SysV/t/sem.t> test, your
+System V IPC may be broken. The XX typically is 20, and that is what ZZZ
also should be. Consider upgrading your OS, or reconfiguring your OS
to include the System V semaphores.
-=item ext/IPC/SysV/t/sem........semget: No space left on device
+=item cpan/IPC-SysV/t/sem........semget: No space left on device
Either your account or the whole system has run out of semaphores. Or
both. Either list the semaphores with "ipcs" and remove the unneeded
UTS may need one or more of -K or -g, and #undef LSTAT.
-FreeBSD can fail the ext/IPC/SysV/t/sem.t test if SysV IPC has not been
+FreeBSD can fail the F<cpan/IPC-SysV/t/sem.t> test if SysV IPC has not been
configured in the kernel. Perl tries to detect this, though, and
you will get a message telling you what to do.
WinCE, ARM Linux, and Solaris. Previous versions of
Perl also provided support for Open Zaurus, Symbian, and
the IBM OS/400, but it's unknown if those ports are still functional.
-These platforms are known as the B<target> platforms, while the systems where the compilation takes place are the B<host> platforms.
+These platforms are known as the B<target> platforms, while the systems
+where the compilation takes place are the B<host> platforms.
What makes the situation difficult is that first of all,
cross-compilation environments vary significantly in how they are set
=item Android
-L<"Cross-compilation" in README.android or perlandroid|perlandroid/Cross-compilation>
+L<"Cross-compilation" in README.android or
+perlandroid|perlandroid/Cross-compilation>
=item Blackberry
=item Solaris
-L<"CROSS-COMPILATION" in README.solaris or perlsolaris|perlsolaris/CROSS-COMPILATION>
+L<"CROSS-COMPILATION" in README.solaris or
+perlsolaris|perlsolaris/CROSS-COMPILATION>
=item Linux
directory>.
About the cross-compilation support of Configure: There's two forms.
-The more common one requires some way of transferring and running executables
-in the target system, such as an ssh connection; this is the
-C<./Configure -Dusecrosscompile -Dtargethost=...> route. The second method
-doesn't need access to the target system, but requires you to provide
-a config.sh, and and a canned Makefile; the rest of this section describes
-the former.
+The more common one requires some way of transferring and running
+executables in the target system, such as an ssh connection; this is the
+C<./Configure -Dusecrosscompile -Dtargethost=...> route. The second
+method doesn't need access to the target system, but requires you to
+provide a config.sh, and and a canned Makefile; the rest of this section
+describes the former.
This cross-compilation setup of Configure has successfully been used in
-a wide variety of setups, such as a 64-bit OS X host for an Android ARM target, or
-an amd64 Linux host targeting x86 Solaris, or even Windows.
+a wide variety of setups, such as a 64-bit OS X host for an Android ARM
+target, or an amd64 Linux host targeting x86 Solaris, or even Windows.
To run Configure in cross-compilation mode the basic switch that
has to be used is C<-Dusecrosscompile>:
-Dtargetuser=luser
but in case you don't, "root" will be used. Similarly, you can specify
-a non-standard (i.e. not 22) port for the connection, if applicable, through
+a non-standard (i.e. not 22) port for the connection, if applicable,
+through
-Dtargetport=2222
(The C<ld> requires more thought and will be chosen later by Configure
as appropriate). This will also aid in guessing the proper
operating system name for the target, which has other repercussions, like
-better defaults and possibly critical fixes for the platform. If Configure
-isn't guessing the OS name properly, you may need to either add a hint file
-redirecting Configure's guess, or modify Configure to make the correct choice.
+better defaults and possibly critical fixes for the platform. If
+Configure isn't guessing the OS name properly, you may need to either add
+a hint file redirecting Configure's guess, or modify Configure to make
+the correct choice.
If your compiler doesn't follow that convention, you will also need to
specify which target environment to use, as well as C<ar> and friends:
-Dar=...
Additionally, a cross-compilation toolchain will usually install it's own
-logical system root somewhere -- that is, it'll create a directory somewhere
-which includes subdirectories like 'include' or 'lib'. For example, you
-may end up with C</skiff/local/arm-linux>, where
-C</skiff/local/arm-linux/bin> holds the binaries for cross-compilation,
-C</skiff/local/arm-linux/include> has the headers, and
-C</skiff/local/arm-linux/lib> has the library files.
+logical system root somewhere -- that is, it'll create a directory
+somewhere which includes subdirectories like C<'include'> or C<'lib'>. For
+example, you may end up with F</skiff/local/arm-linux>, where
+F</skiff/local/arm-linux/bin> holds the binaries for cross-compilation,
+F</skiff/local/arm-linux/include> has the headers, and
+F</skiff/local/arm-linux/lib> has the library files.
If this is the case, and you are using a compiler that understands
C<--sysroot>, like gcc or clang, you'll want to specify the
C<-Dsysroot> option for Configure:
-Dtargetenv="export TMPDIR=/other/tmp;"
-If you are planning on cross-compiling to several platforms, or some other
-thing that would involve running Configure several times, there are two
-options that can be used to speed things up considerably.
+If you are planning on cross-compiling to several platforms, or some
+other thing that would involve running Configure several times, there are
+two options that can be used to speed things up considerably.
As a bit of background, when you
call Configure with C<-Dusecrosscompile>, it begins by actually partially
building a miniperl on the host machine, as well as the generate_uudmap
binary, and we end up using that during the build.
-So instead of building that new perl every single time, you can build it just
-once in a separate directory, and then pass the resulting binaries to
-Configure like this:
+So instead of building that new perl every single time, you can build it
+just once in a separate directory, and then pass the resulting binaries
+to Configure like this:
-Dhostperl=/path/to/second/build/dir/miniperl
-Dhostgenerate=/path/to/second/build/dir/generate_uudmap
these tests might fail. If possible, try running the tests again
with the system under a lighter load. These timing-sensitive
and load-sensitive tests include F<t/op/alarm.t>,
-F<ext/Time-HiRes/t/HiRes.t>, F<ext/threads-shared/t/waithires.t>,
-F<ext/threads-shared/t/stress.t>, F<lib/Benchmark.t>,
+F<dist/Time-HiRes/t/alarm.t>, F<dist/Time-HiRes/t/clock.t>,
+F<dist/Time-HiRes/t/itimer.t>, F<dist/Time-HiRes/t/usleep.t>,
+F<dist/threads-shared/t/waithires.t>,
+F<dist/threads-shared/t/stress.t>, F<lib/Benchmark.t>,
F<lib/Memoize/t/expmod_t.t>, and F<lib/Memoize/t/speed.t>.
You might also experience some failures in F<t/op/stat.t> if you build
=back
The core distribution can now run its regression tests in parallel on
-Unix-like platforms. Instead of running C<make test>, set C<TEST_JOBS> in
-your environment to the number of tests to run in parallel, and run
+Unix-like platforms. Instead of running C<make test>, set C<TEST_JOBS>
+in your environment to the number of tests to run in parallel, and run
C<make test_harness>. On a Bourne-like shell, this can be done as
TEST_JOBS=3 make test_harness # Run 3 tests in parallel
-An environment variable is used, rather than parallel make itself, because
-L<TAP::Harness> needs to be able to schedule individual non-conflicting test
-scripts itself, and there is no standard interface to C<make> utilities to
-interact with their job schedulers.
+An environment variable is used, rather than parallel make itself,
+because L<TAP::Harness> needs to be able to schedule individual
+non-conflicting test scripts itself, and there is no standard interface
+to C<make> utilities to interact with their job schedulers.
=head1 make install
This will put perl into the public directory you specified to
-Configure; by default this is /usr/local/bin. It will also try
-to put the man pages in a reasonable place. It will not nroff the man
-pages, however. You may need to be root to run B<make install>. If you
-are not root, you must still have permission to install into the directories
+Configure; by default this is /usr/local/bin. It will also try to put
+the man pages in a reasonable place. It will not nroff the man pages,
+however. You may need to be root to run B<make install>. If you are not
+root, you must still have permission to install into the directories
in question and you should ignore any messages about chown not working.
If "make install" just says "'install' is up to date" or something
make install PERLNAME=perl5 PERLNAME_VERBASE=perl
-This can be useful if you have to install perl as "perl5" (e.g. to
-avoid conflicts with an ancient version in /usr/bin supplied by your vendor).
+This can be useful if you have to install perl as "perl5" (e.g. to avoid
+conflicts with an ancient version in /usr/bin supplied by your vendor).
Without this the versioned binary would be called "perl55.8.8".
=head2 Installing perl under a different directory
perl,
perl5.n.n where 5.n.n is the current release number. This
will be a link to perl.
- a2p awk-to-perl translator.
scripts
cppstdin This is used by the deprecated switch perl -P,
if your cc -E can't read from stdin.
- c2ph, pstruct Scripts for handling C structures in header
- files.
corelist Shows versions of modules that come with
different
versions of perl.
cpan The CPAN shell.
enc2xs Encoding module generator.
- find2perl find-to-perl translator.
h2ph Extract constants and simple macros from C
headers.
h2xs Converts C .h header files to Perl extensions.
ptar A Perl implementation of tar.
ptardiff A diff for tar archives.
ptargrep A grep for tar archives.
- s2p sed-to-perl translator.
shasum A tool to print or check SHA checksums.
splain Describe Perl warnings and errors.
xsubpp Compiler to convert Perl XS code into C code.
optional Perl compiler, or embed the perl interpreter into another
program even if the Perl source is no longer available.
-=head2 Installing only version-specific parts
+=head2 Installing with a version-specific suffix
-Sometimes you only want to install the version-specific parts of the perl
-installation. For example, you may wish to install a newer version of
-perl alongside an already installed production version without
-disabling installation of new modules for the production version.
+Sometimes you only want to install the perl distribution with a
+version-specific suffix. For example, you may wish to install a newer
+version of perl alongside an already installed production version.
To only install the version-specific parts of the perl installation, run
Configure -Dversiononly
make realclean
The only difference between the two is that make distclean also removes
-your old config.sh and Policy.sh files. (A plain 'make clean' will not
-delete the makefiles used for rebuilding perl, and will also not delete
-a number of library and utility files extracted during the build process.)
+your old config.sh and Policy.sh files. (A plain 'make clean' is now
+equivalent to 'make realclean'.)
If you are upgrading from a previous version of perl, or if you
change systems or compilers or make other significant changes, or if
information about your perl, which may help us track down problems far
more quickly. But first you should read the advice in this file,
carefully re-read the error message and check the relevant manual pages
-on your system, as these may help you find an immediate solution. If
-you are not sure whether what you are seeing is a bug, you can send a
-message describing the problem to the comp.lang.perl.misc newsgroup to
-get advice.
+on your system, as these may help you find an immediate solution.
+Once you've exhausted the documentation, please report bugs to us using
+the 'perlbug' tool.
The perlbug tool is installed along with perl, so after you have
completed C<make install> it should be possible to run it with plain
read your message. Your message will get relayed to over 400
subscribers around the world so please try to keep it brief but clear.
-If the bug you are reporting has security implications, which make it
-inappropriate to send to a publicly archived mailing list, then please send
-it to perl5-security-report@perl.org. This points to a closed subscription
-unarchived mailing list, which includes all the core committers, who be able
-to help assess the impact of issues, figure out a resolution, and help
-co-ordinate the release of patches to mitigate or fix the problem across all
-platforms on which Perl is supported. Please only use this address for security
-issues in the Perl core, not for modules independently distributed on CPAN.
+If the bug you are reporting has security implications which make it
+inappropriate to send to a publicly archived mailing list, then see
+L<perlsec/SECURITY VULNERABILITY CONTACT INFORMATION>
+for details of how to report the issue.
If you are unsure what makes a good bug report please read "How to
report Bugs Effectively" by Simon Tatham:
=head1 Coexistence with earlier versions of perl 5
-Perl 5.21.3 is not binary compatible with earlier versions of Perl.
+Perl 5.26.0 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.X.Y) to another similar minor version (e.g. 5.X.(Y+1))) without
+In general, you can usually safely upgrade from one version of Perl
+(e.g. 5.X.Y) to another similar minor version (e.g. 5.X.(Y+1))) without
re-compiling all of your extensions. You can also safely leave the old
-version around in case the new version causes you problems for some reason.
+version around in case the new version causes you problems for some
+reason.
Usually, most extensions will probably not need to be recompiled to be
used with a newer version of Perl. Here is how it is supposed to work.
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.21.3
+ sh Configure -Dprefix=/opt/perl5.26.0
-and adding /opt/perl5.21.3/bin to the shell PATH variable. Such users
+and adding /opt/perl5.26.0/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.
subversions may not have all the compatibility wrinkles ironed out
yet.
-=head2 Upgrading from 5.21.1 or earlier
+=head2 Upgrading from 5.25.9 or earlier
-B<Perl 5.21.3 may not be binary compatible with Perl 5.21.1 or
+B<Perl 5.26.0 may not be binary compatible with Perl 5.25.9 or
earlier Perl releases.> Perl modules having binary parts
(meaning that a C compiler is used) will have to be recompiled to be
-used with 5.21.3. If you find you do need to rebuild an extension with
-5.21.3, you may safely do so without disturbing the older
+used with 5.26.0. If you find you do need to rebuild an extension with
+5.26.0, you may safely do so without disturbing the older
installations. (See L<"Coexistence with earlier versions of perl 5">
above.)
print("$f\n");
}
-in Linux with perl-5.21.3 is as follows (under $Config{prefix}):
+in Linux with perl-5.26.0 is as follows (under $Config{prefix}):
./bin/perl
- ./lib/perl5/5.21.3/strict.pm
- ./lib/perl5/5.21.3/warnings.pm
- ./lib/perl5/5.21.3/i686-linux/File/Glob.pm
- ./lib/perl5/5.21.3/feature.pm
- ./lib/perl5/5.21.3/XSLoader.pm
- ./lib/perl5/5.21.3/i686-linux/auto/File/Glob/Glob.so
-
-Secondly, for perl-5.10.1, the Debian perl-base package contains 591 files,
-(of which 510 are for lib/unicore) totaling about 3.5MB in its i386 version.
-Omitting the lib/unicore/* files for brevity, the remaining files are:
+ ./lib/perl5/5.26.0/strict.pm
+ ./lib/perl5/5.26.0/warnings.pm
+ ./lib/perl5/5.26.0/i686-linux/File/Glob.pm
+ ./lib/perl5/5.26.0/feature.pm
+ ./lib/perl5/5.26.0/XSLoader.pm
+ ./lib/perl5/5.26.0/i686-linux/auto/File/Glob/Glob.so
+
+Secondly, for perl-5.10.1, the Debian perl-base package contains 591
+files, (of which 510 are for lib/unicore) totaling about 3.5MB in its
+i386 version. Omitting the lib/unicore/* files for brevity, the
+remaining files are:
/usr/bin/perl
/usr/bin/perl5.10.1
https://perl5.git.perl.org / perl5.git / blobdiff