X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=INSTALL;h=00380e3b567b34b43e5c54061a2bea9fa5c6a668;hb=452932c35a5cd0aae80a37f9e3a551b9fc75f50d;hp=cb73d2127df7aad6defb9b21cf0d9905611d016e;hpb=8267c26231a981c8bf518d9a17713993cce69149;p=p5sagit%2Fp5-mst-13.2.git diff --git a/INSTALL b/INSTALL index cb73d21..00380e3 100644 --- a/INSTALL +++ b/INSTALL @@ -321,12 +321,14 @@ find it. It's often a good idea to have both /usr/bin/perl and careful, however, not to overwrite a version of perl supplied by your vendor unless you are sure you know what you are doing. -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 +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 -Uinstallusrbinperl + Configure -Dinstallusrbinperl -or by answering 'no' to the appropriate Configure prompt. +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, @@ -438,10 +440,10 @@ be used for installing those add-on modules and scripts. $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. @@ -459,10 +461,10 @@ for you to use to distribute add-on modules. $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: @@ -484,15 +486,15 @@ This would have the effect of setting the following: $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 @@ -650,6 +652,18 @@ Here's one way to do that: cd /opt/perl # Or wherever you specified as $prefix tar xvf perl5-archive.tar +Alternatively, the DESTDIR variable is honored during C. +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" @@ -836,6 +850,38 @@ Configure should detect this problem and warn you about problems with _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. Another option is to add +-DUSE_HASH_SEED_EXPLICIT to the compilation flags (for example by +using C), 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, 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 option is recommended. + =head2 SOCKS Perl can be configured to be 'socksified', that is, to use the SOCKS @@ -942,10 +988,14 @@ 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 -version of perl. You can do this by changing all the *archlib* -variables in config.sh to point to your new architecture-dependent library. +In other words, it is generally not a good idea to try to build a perl +with a shared library if $archlib/CORE/$libperl already exists from a +previous build. + +A good workaround is to specify a different directory for the +architecture-dependent library for your -DDEBUGGING version of perl. +You can do this by changing all the *archlib* variables in config.sh to +point to your new architecture-dependent library. =head2 Malloc Issues