page, rather than the B<less> program.
If you specify a prefix that contains the string "perl", then the
-directory structure is simplified. For example, if you Configure
-with -Dprefix=/opt/perl, then the defaults are
+directory structure is simplified. For example, if you Configure with
+-Dprefix=/opt/perl, then the defaults are
/opt/perl/lib/archname/5.004
/opt/perl/lib
packages may also wish to install perl into a different directory and
use that management software to move perl to its final destination.
This section describes how to do this. Someday, Configure may support
-an option C<-Dinstallprefix=/foo> to simplify this.
+an option -Dinstallprefix=/foo to simplify this.
Suppose you want to install perl under the F</tmp/perl5> directory.
You can edit F<config.sh> and change all the install* variables to
that you have sfio, then sfio will be the default suggested by
Configure.
+I<Note:> On some systems, sfio's B<iffe> configuration script fails
+to detect that you have an C<atexit> function (or equivalent).
+Apparently, this is a problem at least for some versions of Linux
+and SunOS 4.
+
+You can test if you have this problem by trying the following shell
+script. (You may have to add some extra cflags and libraries. A
+portable version of this may eventually make its way into Configure.)
+
+ #!/bin/sh
+ cat > try.c <<'EOCP'
+ #include <stdio.h>
+ main() { printf("42\n"); }
+ EOCP
+ cc -o try try.c -lsfio
+ val=`./try`
+ if test X$val = X42; then
+ echo "Your sfio looks ok"
+ else
+ echo "Your sfio has the exit problem."
+ fi
+
+If you have this problem, the fix is to go back to your sfio sources
+and correct iffe's guess about atexit (or whatever is appropriate for
+your platform.)
+
+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
variables in config.sh, namely archlib, archlib_exp, and
installarchlib, to point to your new architecture-dependent library.
+=head2 Malloc Issues
+
+Perl relies heavily on malloc(3) to grow data structures as needed, so
+perl's performance can be noticeably affected by the performance of
+the malloc function on your system.
+
+The perl source is shipped with a version of malloc that is very fast
+but somewhat wasteful of space. On the other hand, your system's
+malloc() function is probably a bit slower but also a bit more frugal.
+
+For many uses, speed is probably the most important consideration, so
+the default behavior (for most systems) is to use the malloc supplied
+with perl. However, if you will be running very large applications
+(e.g. Tk or PDL) or if your system already has an excellent malloc, or
+if you are experiencing difficulties with extensions that use
+third-party libraries that call malloc, then you might wish to use
+your system's malloc. (Or, you might wish to explore the experimental
+malloc flags discussed below.)
+
+To build without perl's malloc, you can use the Configure command
+
+ sh Configure -Uusemymalloc
+
+or you can answer 'n' at the appropriate interactive Configure prompt.
+
+=head2 Malloc Performance Flags
+
+If you are using Perl's malloc, you may add one or
+more of the following items to your C<cflags> config.sh variable
+to change its behavior in potentially useful ways. You can find out
+more about these flags by reading the F<malloc.c> source.
+In a future version of perl, these might be enabled by default.
+
+=over 4
+
+=item -DEMERGENCY_SBRK
+
+If this macro is defined, running out of memory need not be a fatal
+error: a memory pool can allocated by assigning to the special
+variable C<$^M>.
+
+=item -DPACK_MALLOC
+
+If C<PACK_MALLOC> is defined, malloc.c uses a slightly different
+algorithm for small allocations (up to 64 bytes long). Such small
+allocations are quite common in typical Perl scripts.
+
+The expected memory savings (with 8-byte alignment in C<alignbytes>) is
+about 20% for typical Perl usage. The expected slowdown due to the
+additional malloc overhead is in fractions of a percent. (It is hard
+to measure because of the effect of the saved memory on speed).
+
+=item -DTWO_POT_OPTIMIZE
+
+If C<TWO_POT_OPTIMIZE> is defined, malloc.c uses a slightly different
+algorithm for large allocations that are close to a power of two
+(starting with 16K). Such allocations are typical for big hashes and
+special-purpose scripts, especially image processing. If you will be
+manipulating very large blocks with sizes close to powers of two, it
+might be wise to define this macro.
+
+The expected saving of memory is 0-100% (100% in applications which
+require most memory in such 2**n chunks). The expected slowdown is
+negligible.
+
+=back
+
=head2 Other Compiler Flags
For most users, all of the Configure defaults are fine. However,
you can change a number of factors in the way perl is built
-by adding appropriate -D directives to your ccflags variable in
+by adding appropriate B<-D> directives to your ccflags variable in
config.sh.
For example, you can replace the rand() and srand() functions in the
=item *
-If you get duplicates upon linking for malloc et al,
-add -DHIDEMYMALLOC to your ccflags variable in config.sh.
+If you get duplicates upon linking for malloc et al, add -DHIDEMYMALLOC
+or -DEMBEDMYMALLOC to your ccflags variable in config.sh.
=item varargs
NCR Tower 32 (OS 2.01.01) may need -W2,-Sl,2000 and #undef MKDIR.
-UTS may need one or more of B<-DCRIPPLED_CC>, B<-K> or B<-g>, and undef LSTAT.
+UTS may need one or more of -DCRIPPLED_CC, B<-K> or B<-g>, and undef LSTAT.
If you get syntax errors on '(', try -DCRIPPLED_CC.
=head1 LAST MODIFIED
-18 February 1997
+$Id: INSTALL,v 1.3 1997/02/28 16:34:11 doughera Released $
projects / p5sagit/p5-mst-13.2.git / blobdiff