After it runs, Configure will perform variable substitution on all the
*.SH files and offer to run make depend.
-Configure supports a number of useful options. Run B<Configure -h>
-to get a listing. To compile with gcc, for example, you can run
+Configure supports a number of useful options. Run B<Configure -h> to
+get a listing. See the Porting/Glossary file for a complete list of
+Configure variables you can set and their definitions.
+
+To compile with gcc, for example, you should run
sh Configure -Dcc=gcc
then Configure will suggest /opt/perl/lib instead of
/opt/perl/lib/perl5/.
+NOTE: You must not specify an installation directory that is below
+your perl source directory. If you do, installperl will attempt
+infinite recursion.
+
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
(Actually, Configure recognizes the SVR3-style
/usr/local/man/l_man/man1 directories, if present, and uses those
-instead.) The module man pages are stuck in that strange spot so that
+instead.)
+
+The module man pages are stuck in that strange spot so that
they don't collide with other man pages stored in /usr/local/man/man3,
and so that Perl's man pages don't hide system man pages. On some
systems, B<man less> would end up calling up Perl's less.pm module man
-page, rather than the less program. (This location may change in a
-future release of perl.)
+page, rather than the less program. (This default location will likely
+change to /usr/local/man/man3 in a future release of perl.)
Note: Many users prefer to store the module man pages in
/usr/local/man/man3. You can do this from the command line with
make test
make install
cd /tmp/perl5
+ # Edit lib/<archname>/<version>/Config.pm to change all the
+ # install* variables back to reflect where everything will
+ # really be installed.
tar cvf ../perl5-archive.tar .
# Then, on each machine where you want to install perl,
cd /usr/local # Or wherever you specified as $prefix
=head2 Binary Compatibility With Earlier Versions of Perl 5
-If you have dynamically loaded extensions that you built under
-perl 5.003 and that you wish to continue to use with perl 5.004, then you
-need to ensure that 5.004 remains binary compatible with 5.003.
-
-Starting with Perl 5.003, all functions in the Perl C source code have
-been protected by default by the prefix Perl_ (or perl_) so that you
-may link with third-party libraries without fear of namespace
-collisions. This change broke compatibility with version 5.002, so
-installing 5.003 or 5.004 over 5.002 or earlier will force you to
-re-build and install all of your dynamically loadable extensions.
-(The standard extensions supplied with Perl are handled
+For Perl 5.004 it was possible to be binary compatible with 5.003.
+Starting from Perl 5.005 this is no more possible because there were
+many deep and far-reaching changes to the language internals.
+
+If you have dynamically loaded extensions that you built under perl
+5.003 or 5.004 and the so-called 'bincompat3' mode (the default mode)
+and that you wish to continue to use with perl 5.005, you may need to
+reinstall the extensions.
+
+Background: starting with Perl 5.003, all functions in the Perl C
+source code have been protected by default by the prefix Perl_ (or
+perl_) so that you may link with third-party libraries without fear of
+namespace collisions. This change broke compatibility with version
+5.002, so installing 5.003 or 5.004 over 5.002 or earlier will force
+you to re-build and install all of your dynamically loadable
+extensions. (The standard extensions supplied with Perl are handled
automatically). You can turn off this namespace protection by adding
-DNO_EMBED to your ccflags variable in config.sh.
-Perl 5.003's namespace protection was incomplete, but this has
-been fixed in 5.004. However, some sites may need to maintain
-complete binary compatibility with Perl 5.003. If you are building
-Perl for such a site, then when Configure asks if you want binary
-compatibility, answer "y".
-
-On the other hand, if you are embedding perl into another application
-and want the maximum namespace protection, then you probably ought to
-answer "n" when Configure asks if you want binary compatibility.
-
-The default answer of "y" to maintain binary compatibility is probably
-appropriate for almost everyone.
-
-In a related issue, old extensions may possibly be affected by the changes
-in the Perl language in the current release. Please see pod/perldelta for
-a description of what's changed.
+In a related issue, old extensions may possibly be affected by the
+changes in the Perl language in the current release. Please see
+pod/perldelta.pod for a description of what's changed.
=head2 Selecting File IO mechanisms
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 with by changing all the *archlib*
+version of perl. You can do this by changing all the *archlib*
variables in config.sh, namely archlib, archlib_exp, and
installarchlib, to point to your new architecture-dependent library.
=over 4
-=item -DDEBUGGING_MSTATS
-
-If DEBUGGING_MSTATS is defined, you can extract malloc
-statistics from the Perl interpreter. The overhead this imposes is not
-large (perl just twiddles integers at malloc/free/sbrk time). When you
-run perl with the environment variable PERL_DEBUG_MSTATS set to
-either 1 or 2, the interpreter will dump statistics to stderr at exit
-time and (with a value of 2) after compilation. If you install the
-Devel::Peek module you can get the statistics whenever you like by
-invoking its mstat() function.
-
-=item -DEMERGENCY_SBRK
+=item -DPERL_EMERGENCY_SBRK
-If EMERGENCY_SBRK is defined, running out of memory need not be a
+If PERL_EMERGENCY_SBRK is defined, running out of memory need not be a
fatal error: a memory pool can allocated by assigning to the special
variable $^M. See perlvar(1) for more details.
for Solaris systems. For a SunOS system, you must use -B/bin/
instead.
+Alternatively, recent versions of GNU ld reportedly work if you
+include C<-Wl,-export-dynamic> in the ccdlflags variable in
+config.sh.
+
=item ld.so.1: ./perl: fatal: relocation error:
If you get this message on SunOS or Solaris, and you're using gcc,
fork() function. Follow the procedure in the previous items
on L<"vsprintf"> and L<"nm extraction">.
+=item __inet_* errors
+
+If you receive unresolved symbol errors during Perl build and/or test
+referring to __inet_* symbols, check to see whether BIND 8.1 is
+installed. It installs a /usr/local/include/arpa/inet.h that refers to
+these symbols. Versions of BIND later than 8.1 do not install inet.h
+in that location and avoid the errors. You should probably update to a
+newer version of BIND. If you can't, you can either link with the
+updated resolver library provided with BIND 8.1 or rename
+/usr/local/bin/arpa/inet.h during the Perl build and test process to
+avoid the problem.
+
=item Optimizer
If you can't compile successfully, try turning off your compiler's
=head1 make test
-This will run the regression tests on the perl you just made. If it
-doesn't say "All tests successful" then something went wrong. See the
-file t/README in the t subdirectory. Note that you can't run the
-tests in background if this disables opening of /dev/tty.
+This will run the regression tests on the perl you just made (you
+should run plain 'make' before 'make test' otherwise you won't have a
+complete build). If 'make test' doesn't say "All tests successful"
+then something went wrong. See the file t/README in the t subdirectory.
+
+Note that you can't run the tests in background if this disables
+opening of /dev/tty. You can use 'make test-notty' in that case but
+a few tty tests will be skipped.
If make test bombs out, just cd to the t directory and run ./TEST
by hand to see if it makes any difference. If individual tests
./perl harness
-(this assumes that most tests succeed, since harness uses
+(this assumes that most basic tests succeed, since harness uses
complicated constructs).
-You can also read the individual tests to see if there are any helpful
+You should also read the individual tests to see if there are any helpful
comments that apply to your system.
Note: One possible reason for errors is that some external programs
correctly. For example, h2ph breaks spectacularly on type casting and
certain structures.
-=head installhtml --help
+=head1 installhtml --help
Some sites may wish to make perl documentation available in HTML
format. The installhtml utility can be used to convert pod
-documentation into linked HTML files and install install them.
+documentation into linked HTML files and install them.
-The following command-line is an example of the one we use to convert
+The following command-line is an example of one used to convert
perl documentation:
./installhtml \
resolve" as the files are processed. We are aware of these problems
(and would welcome patches for them).
+You may find it helpful to run installhtml twice. That should reduce
+the number of "cannot resolve" warnings.
+
=head1 cd pod && make tex && (process the latex files)
Some sites may also wish to make the documentation in the pod/ directory
=head1 AUTHOR
-Andy Dougherty doughera@lafcol.lafayette.edu , borrowing very heavily
-from the original README by Larry Wall, and also with lots of helpful
-feedback from the perl5-porters@perl.org folks.
+Original author: Andy Dougherty doughera@lafcol.lafayette.edu ,
+borrowing very heavily from the original README by Larry Wall,
+with lots of helpful feedback and additions from the
+perl5-porters@perl.org folks.
+
+If you have problems or questions, please see L<"Reporting Problems">
+above.
=head1 LAST MODIFIED
-$Id: INSTALL,v 1.18 1997/05/29 18:24:10 doughera Exp $
+$Id: INSTALL,v 1.28 1997/10/10 16:50:59 doughera Released $
projects / p5sagit/p5-mst-13.2.git / blobdiff