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.
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,
$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
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"
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
_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
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.
+
+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.
-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.
+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
does not allow its malloc functions to be fully replaced with custom
versions.
+=item -DPERL_DEBUGGING_MSTATS
+
+This flag enables debugging mstats, which is required to use the
+Devel::Peek::mstat() function. You cannot enable this unless you are
+using Perl's malloc, so a typical Configure command would be
+
+ sh Configure -Accflags=-DPERL_DEBUGGING_MSTATS -Dusemymalloc='y'
+
+to enable this option.
+
=back
=head2 Building a debugging perl
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.
+To disable certain extensions so that they are not built, use
+the -Dnoextensions=... and -Donlyextensions=... options. They both
+accept a space-separated list of extensions. The extensions listed
+in C<noextensions> are removed from the list of extensions to build,
+while the C<onlyextensions> is rather more severe and builds only
+the listed extensions. The latter should be used with extreme caution
+since certain extensions are used by many other extensions and modules:
+such modules include Fcntl and IO. The order of processing these
+options is first C<only> (if present), then C<no> (if present).
+
+Another, older way to turn off various extensions (which is still good
+to know if you have to work with older Perl) exists. 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)
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 Bad arg length for semctl, is XX, should be ZZZ
-If you get this error message from the lib/ipc_sysv test, your System
+If you get this error message from the ext/IPC/SysV/t/sem test, your System
V IPC may be broken. The XX typically is 20, and that is what ZZZ
also should be. Consider upgrading your OS, or reconfiguring your OS
to include the System V semaphores.
-=item lib/ipc_sysv........semget: No space left on device
+=item ext/IPC/SysV/t/sem........semget: No space left on device
Either your account or the whole system has run out of semaphores. Or
both. Either list the semaphores with "ipcs" and remove the unneeded
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
+FreeBSD can fail the ext/IPC/SysV/t/sem.t test if SysV IPC has not been
configured in the kernel. Perl tries to detect this, though, and
you will get a message telling what to do.
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
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
https://perl5.git.perl.org / perl5.git / blobdiff