-Note: Since the directory hierarchy for 5.6.0 contains a number of
-new vendor* and site* entries, your Policy.sh file will probably not
-set them to your desired values. I encourage you to run Configure
-interactively to be sure it puts things where you want them.
-
-=head2 Configure-time Options
-
-There are several different ways to Configure and build perl for your
-system. For most users, the defaults are sensible and will work.
-Some users, however, may wish to further customize perl. Here are
-some of the main things you can change.
-
-=head2 Threads
-
-On some platforms, perl5.005 and later can be compiled with
-experimental support for threads. To enable this, read the file
-README.threads, and then try:
-
- sh Configure -Dusethreads
-
-Currently, you need to specify -Dusethreads on the Configure command
-line so that the hint files can make appropriate adjustments.
-
-The default is to compile without thread support.
-
-As of v5.5.64, perl has two different internal threads implementations.
-The 5.005 version (5005threads) and an interpreter-based implementation
-(ithreads) with one interpreter per thread. By default, Configure selects
-ithreads if -Dusethreads is specified. However, you can select the old
-5005threads behavior instead by either
-
- sh Configure -Dusethreads -Duse5005threads
-
-or by
- sh Configure -Dusethreads -Uuseithreads
-
-Eventually (by perl v5.6.0) this internal confusion ought to disappear,
-and these options may disappear as well.
-
-=head2 Large file support.
-
-Since Perl 5.6.0 Perl has supported large files (files larger than
-2 gigabytes), and in many common platforms like Linux or Solaris this
-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 if you are interfacing Perl
-using some extension, also the components you are connecting to must
-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. One popular extension suffering from this ailment is the
-Apache extension mod_perl.
-
-There's also one known limitation with the current large files
-implementation: unless you also have 64-bit integers (see the next
-section), you cannot use the printf/sprintf non-decimal integer
-formats like C<%x> to print filesizes. You can use C<%d>, though.
-
-=head2 64 bit support.
-
-If your platform does not have 64 bits natively, but can simulate them
-with compiler flags and/or C<long long> or C<int64_t>, you can build a
-perl that uses 64 bits.
-
-There are actually two modes of 64-bitness: the first one is achieved
-using Configure -Duse64bitint and the second one using Configure
--Duse64bitall. The difference is that the first one is minimal and
-the second one maximal. The first works in more places than the second.
-
-The C<use64bitint> does only as much as is required to get 64-bit
-integers into Perl (this may mean, for example, using "long longs")
-while your memory may still be limited to 2 gigabytes (because your
-pointers could still be 32-bit). Note that the name C<64bitint> does
-not imply that your C compiler will be using 64-bit C<int>s (it might,
-but it doesn't have to): the C<use64bitint> means that you will be
-able to have 64 bits wide scalar values.
-
-The C<use64bitall> goes all the way by attempting to switch also
-integers (if it can), longs (and pointers) to being 64-bit. This may
-create an even more binary incompatible Perl than -Duse64bitint: the
-resulting executable may not run at all in a 32-bit box, or you may
-have to reboot/reconfigure/rebuild your operating system to be 64-bit
-aware.
-
-Natively 64-bit systems like Alpha and Cray need neither -Duse64bitint
-nor -Duse64bitall.
-
- NOTE: 64-bit support is still experimental on most platforms.
- Existing support only covers the LP64 data model. In particular, the
- LLP64 data model is not yet supported. 64-bit libraries and system
- APIs on many platforms have not stabilized--your mileage may vary.
-
-=head2 Long doubles
-
-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).
-
-=head2 "more bits"
-
-You can "Configure -Dusemorebits" to turn on both the 64-bit support
-and the long double support.
-
-=head2 Selecting File IO mechanisms
-
-Previous versions of perl used the standard IO mechanisms as defined in
-stdio.h. Versions 5.003_02 and later of perl allow alternate IO
-mechanisms via a "PerlIO" abstraction, but the stdio mechanism is still
-the default and is the only supported mechanism.
-
-This PerlIO abstraction can be enabled either on the Configure command
-line with
-
- sh Configure -Duseperlio
-
-or interactively at the appropriate Configure prompt.
-
-If you choose to use the PerlIO abstraction layer, there are two
-(experimental) possibilities for the underlying IO calls. These have been
-tested to some extent on some platforms, but are not guaranteed to work
-everywhere.
-
-=over 4
-
-=item 1.
-
-AT&T's "sfio". This has superior performance to stdio.h in many
-cases, and is extensible by the use of "discipline" modules. Sfio
-currently only builds on a subset of the UNIX platforms perl supports.
-Because the data structures are completely different from stdio, perl
-extension modules or external libraries may not work. This
-configuration exists to allow these issues to be worked on.
-
-This option requires the 'sfio' package to have been built and installed.
-The latest sfio is available from http://www.research.att.com/sw/tools/sfio/
-
-You select this option by
-
- sh Configure -Duseperlio -Dusesfio
-
-If you have already selected -Duseperlio, and if Configure detects
-that you have sfio, then sfio will be the default suggested by
-Configure.
-
-Note: On some systems, sfio's iffe configuration script fails to
-detect that you have an atexit function (or equivalent). Apparently,
-this is a problem at least for some versions of Linux and SunOS 4.
-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.
-
-=item 2.
-
-Normal stdio IO, but with all IO going through calls to the PerlIO
-abstraction layer. This configuration can be used to check that perl and
-extension modules have been correctly converted to use the PerlIO
-abstraction.
-
-This configuration should work on all platforms (but might not).
-
-You select this option via:
-
- sh Configure -Duseperlio -Uusesfio
-
-If you have already selected -Duseperlio, and if Configure does not
-detect sfio, then this will be the default suggested by Configure.
-
-=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
-your system supports it. If you want to force perl to be compiled
-statically, you can either choose this when Configure prompts you or
-you can use the Configure command line option -Uusedl.
-
-=head2 Building a shared libperl.so 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 (usually just DynaLoader.a) and various extra libraries,
-such as -lm.
-
-On some 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.3.2 (for Perl 5.003_02) or libperl.so.302 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.
-
-For some systems (mostly SVR4), building a shared libperl is required
-for dynamic loading to work, and hence is already the default.
-
-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, LIBRARY_PATH for BeOS, 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.