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
+maintenance releases and odd-numbered subreleases (like 5.7) are
+unstable development releases. Development releases should not be
+used in production environments. Fixes and new features are first
+carefully tested in development releases and only if they prove
+themselves to be worthy will they be migrated to the maintenance
+releases.
+
The above commands will install Perl to /usr/local or /opt, depending
on the platform. If that's not okay with you, use
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.com to let us know the steps you
+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
sh Configure -des
-For my Solaris system, I usually use
+Note: for development releases (odd subreleases, like 5.7, as opposed
+to maintenance releases which have even subreleases, like 5.6)
+if you want to use Configure -d, you will also need to supply -Dusedevel
+to Configure, because the default answer to the question "do you really
+want to Configure a development version?" is "no". The -Dusedevel
+skips that sanity check.
+
+For example for my Solaris system, I usually use
sh Configure -Dprefix=/opt/perl -Doptimize='-xpentium -xO4' -des
configuration exists to allow these issues to be worked on.
This option requires the 'sfio' package to have been built and installed.
-A (fairly old) version of sfio is in CPAN.
+The latest sfio is available from http://www.research.att.com/sw/tools/sfio/
You select this option by
_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.
-There also might be a more recent release of Sfio that fixes your
-problem.
-
=item 2.
Normal stdio IO, but with all IO going through calls to the PerlIO
=back
+=head2 SOCKS
+
+Perl can be configured to be 'socksified', that is, to use the SOCKS
+TCP/IP proxy protocol library. SOCKS is used to give applications
+access to transport layer network proxies. Perl supports only SOCKS
+Version 5. You can find more about SOCKS from http://www.socks.nec.com/
+
=head2 Dynamic Loading
By default, Configure will compile perl to use dynamic loading if
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 test are being run in is writable by group
+or by other (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 the
+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).
+
+See the documentation for the File::Temp module for more information
+about the various security aspects.
+
=back
=head1 make install
If you have difficulty building perl, and none of the advice in this file
helps, and careful reading of the error message and the relevant manual
pages on your system doesn't help either, then you should send a message
-to either the comp.lang.perl.misc newsgroup or to perlbug@perl.com with
+to either the comp.lang.perl.misc newsgroup or to perlbug@perl.org with
an accurate description of your problem.
Please include the output of the ./myconfig shell script that comes with
projects / p5sagit/p5-mst-13.2.git / blobdiff