+In some systems you may be able to use long doubles to enhance the
+range and precision of your double precision floating point numbers
+(that is, Perl's numbers). Use Configure -Duselongdouble to enable
+this support (if it is available).
+
+=head3 "more bits"
+
+You can "Configure -Dusemorebits" to turn on both the 64-bit support
+and the long double support.
+
+=head3 Algorithmic Complexity Attacks on Hashes
+
+Perl 5.18 reworked the measures used to secure its hash function
+from algorithmic complexity attacks. By default it will build with
+all of these measures enabled along with support for controlling and
+disabling them via environment variables.
+
+You can override various aspects of this feature by defining various
+symbols during configure. An example might be:
+
+ Configure -Accflags=-DPERL_HASH_FUNC_SIPHASH
+
+B<Unless stated otherwise these options are considered experimental or
+insecure and are not recommended for production use.>
+
+Perl 5.18 includes support for multiple hash functions, and changed
+the default (to ONE_AT_A_TIME_HARD), you can choose a different
+algorithm by defining one of the following symbols. Note that as of
+Perl 5.18 we can only recommend use of the default or SIPHASH. All
+the others are known to have security issues and are for research
+purposes only.
+
+ PERL_HASH_FUNC_SIPHASH
+ PERL_HASH_FUNC_SDBM
+ PERL_HASH_FUNC_DJB2
+ PERL_HASH_FUNC_SUPERFAST
+ PERL_HASH_FUNC_MURMUR3
+ PERL_HASH_FUNC_ONE_AT_A_TIME
+ PERL_HASH_FUNC_ONE_AT_A_TIME_HARD
+ PERL_HASH_FUNC_ONE_AT_A_TIME_OLD
+
+Perl 5.18 randomizes the order returned by keys(), values(), and each(),
+and allows controlling this behavior by using of the PERL_PERTURB_KEYS
+option. You can disable this option entirely with the define:
+
+ PERL_PERTURB_KEYS_DISABLED
+
+You can disable the environment variable checks and specify the type of
+key traversal randomization to be used by defining one of these:
+
+ PERL_PERTURB_KEYS_RANDOM
+ PERL_PERTURB_KEYS_DETERMINISTIC
+
+In Perl 5.18 the seed used for the hash function is randomly selected
+at process start which can be overridden by specifying a seed by setting
+the PERL_HASH_SEED environment variable.
+
+You can change this behavior by building perl with the
+
+ USE_HASH_SEED_EXPLICIT
+
+define, in which case one has to explicitly set the PERL_HASH_SEED
+environment variable to enable the security feature or by adding
+
+ NO_HASH_SEED
+
+to the compilation flags to completely disable the randomisation feature.
+Note these modes are poorly tested, insecure and not recommended.
+
+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.
+
+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.
+
+=head3 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. The corresponding Configure option is -Dusesocks.
+You can find more about SOCKS from wikipedia at
+L<http://en.wikipedia.org/wiki/SOCKS>.
+
+=head3 Dynamic Loading
+
+By default, Configure will compile perl to use dynamic loading.
+If you want to force perl to be compiled completely
+statically, you can either choose this when Configure prompts you or
+you can use the Configure command line option -Uusedl.
+With this option, you won't be able to use any new extension
+(XS) module without recompiling perl itself.
+
+=head3 Building a shared Perl library
+
+Currently, for most systems, the main perl executable is built by
+linking the "perl library" libperl.a with perlmain.o, your static
+extensions, and various extra libraries, such as -lm.
+
+On systems that support dynamic loading, it may be possible to
+replace libperl.a with a shared libperl.so. If you anticipate building
+several different perl binaries (e.g. by embedding libperl into
+different programs, or by using the optional compiler extension), then
+you might wish to build a shared libperl.so so that all your binaries
+can share the same library.
+
+The disadvantages are that there may be a significant performance
+penalty associated with the shared libperl.so, and that the overall
+mechanism is still rather fragile with respect to different versions
+and upgrades.
+
+In terms of performance, on my test system (Solaris 2.5_x86) the perl
+test suite took roughly 15% longer to run with the shared libperl.so.
+Your system and typical applications may well give quite different
+results.
+
+The default name for the shared library is typically something like
+libperl.so.5.8.8 (for Perl 5.8.8), or libperl.so.588, or simply
+libperl.so. Configure tries to guess a sensible naming convention
+based on your C library name. Since the library gets installed in a
+version-specific architecture-dependent directory, the exact name
+isn't very important anyway, as long as your linker is happy.
+
+You can elect to build a shared libperl by
+
+ sh Configure -Duseshrplib
+
+To build a shared libperl, the environment variable controlling shared
+library search (LD_LIBRARY_PATH in most systems, DYLD_LIBRARY_PATH for
+NeXTSTEP/OPENSTEP/Darwin, LD_LIBRARY_PATH/SHLIB_PATH
+for HP-UX, LIBPATH for AIX, PATH for Cygwin) must be set up to include
+the Perl build directory because that's where the shared libperl will
+be created. Configure arranges makefile to have the correct shared
+library search settings. You can find the name of the environment
+variable Perl thinks works in your your system by
+
+ grep ldlibpthname config.sh
+
+However, there are some special cases where manually setting the
+shared library path might be required. For example, if you want to run
+something like the following with the newly-built but not-yet-installed
+./perl:
+
+ ./perl -MTestInit t/misc/failing_test.t
+
+or
+
+ ./perl -Ilib ~/my_mission_critical_test
+
+then you need to set up the shared library path explicitly.
+You can do this with
+
+ LD_LIBRARY_PATH=`pwd`:$LD_LIBRARY_PATH; export LD_LIBRARY_PATH
+
+for Bourne-style shells, or
+
+ setenv LD_LIBRARY_PATH `pwd`
+
+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 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),
+for example:
+
+ 18126:./miniperl: /sbin/loader: Fatal Error: cannot map libperl.so
+
+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.10.0 with a shared library. Then, suppose you
+try to build Perl 5.10.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.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 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.
+
+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.
+
+=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.