view release on metacpan or  search on metacpan

etc/INSTALL.html  view on Meta::CPAN

<EM>*</EM>
</STRONG></DT>
<DD>

If you used a hint file, try reading the comments in the hint file
for further tips and information.
<p></DD>
<DT><STRONG>
<EM>*</EM>
</STRONG></DT>
<DD>

If you can't compile successfully, try adding a <CODE>-DCRIPPLED_CC</CODE> flag.
(Just because you get no errors doesn't mean it compiled right!)
This simplifies some complicated expressions for compilers that
get indigestion easily.  If that has no effect, try turning off
optimization.  If you have missing routines, you probably need to
add some library or other, or you need to undefine some feature that
Configure thought was there but is defective or incomplete.
<p></DD>
<DT><STRONG>
<EM>*</EM>
</STRONG></DT>
<DD>

Some compilers will not compile or optimize the larger files without
some extra switches to use larger jump offsets or allocate larger
internal tables.  You can customize the switches for each file in

<A HREF="INSTALL.html#INSTALL_cflags_0">cflags</A>
.  It's okay to insert rules for specific files into
<EM>makefile</EM> since a default rule only takes effect in the absence of a
specific rule.
<p></DD>
<DT><STRONG>
<EM>*</EM>
</STRONG></DT>
<DD>

If you can successfully build <EM>miniperl</EM>, but the process crashes
during the building of extensions, you should run
<p><UL><LI>    	make minitest</LI>
</UL>
<p>to test your version of miniperl.
<p></DD>
<DT><STRONG>
<EM>*</EM>
</STRONG></DT>
<DD>

Some additional things that have been reported for either perl4 or perl5:
<p>Genix may need to use libc rather than libc_s, or #undef VARARGS.
<p>NCR Tower 32 (OS 2.01.01) may need -W2,-Sl,2000 and #undef MKDIR.
<p>UTS may need one or more of <STRONG>-DCRIPPLED_CC</STRONG>, <STRONG>-K</STRONG> or <STRONG>-g</STRONG>, and undef LSTAT.
<p>If you get syntax errors on '(', try -DCRIPPLED_CC.
<p>Machines with half-implemented dbm routines will need to #undef I_ODBM
<p>SCO prior to 3.2.4 may be missing <EM>dbmclose()</EM>.  An upgrade to 3.2.4
that includes libdbm.nfs (which includes <EM>dbmclose()</EM>) may be available.
<p>If you get duplicates upon linking for malloc et al, say -DHIDEMYMALLOC.
<p>If you get duplicate function definitions (a perl function has the
same name as another function on your system) try -DEMBED.
<p>If you get varags problems with gcc, be sure that gcc is installed
correctly.  When using gcc, you should probably have i_stdarg='define'
and i_varags='undef' in config.sh.  The problem is usually solved
by running fixincludes correctly.
<p>If you wish to use dynamic loading on SunOS or Solaris, and you
have GNU as and GNU ld installed, you may need to add <STRONG>-B/bin/</STRONG> to
your <STRONG>$ccflags</STRONG> and <STRONG>$ldflags</STRONG> so that the system's versions of as
and ld are used.
<p>If you run into dynamic loading problems, check your setting of
the LD_LIBRARY_PATH environment variable.  Perl should build
fine with LD_LIBRARY_PATH unset, though that may depend on details
of your local set-up.
<p>If Configure seems to be having trouble finding library functions,
try not using nm extraction.  You can do this from the command line
with
<p>
<XMP>
        sh Configure -Uusenm

</XMP>
<p></DD>
</DL>
.
<p><p><hr>

<H1> 
<A NAME="INSTALL_make_2">
make test</A>
</H1>

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 <EM>t/README</EM> in the <EM>t</EM> subdirectory.  Note that you can't run it
in background if this disables opening of /dev/tty.  If 
<A HREF="INSTALL.html#INSTALL_make_2">make test</A>

bombs out, just <STRONG>cd</STRONG> to the <EM>t</EM> directory and run <STRONG>TEST</STRONG> by hand
to see if it makes any difference.
If individual tests bomb, you can run them by hand, e.g.,
<p>
<XMP>
        ./perl op/groups.t

</XMP>
<p><STRONG>NOTE</STRONG>: one possible reason for errors is that some external programs
may be broken due to the combination of your environment and the way

<A HREF="INSTALL.html#INSTALL_make_2">make test</A>
 exercises them. This may happen for example if you have
one or more of these environment variables set:
<CODE>LC_ALL LC_CTYPE LANG</CODE>. In certain UNIXes especially the non-English
locales are known to cause programs to exhibit mysterious errors.
If you have any of the above environment variables set, please try
<CODE>setenv LC_ALL C</CODE> or&lt;LC_ALL=C;export LC_ALL&gt;, for <CODE>csh</CODE>-style and
<CODE>Bourne</CODE>-style shells, respectively, from the command line and then
retry 
<A HREF="INSTALL.html#INSTALL_make_2">make test</A>
. If the tests then succeed, you may have a broken
program that is confusing the testing. Please run the troublesome test
by hand as shown above and see whether you can locate the program.