source: trunk/essentials/dev-lang/perl/README.mint@ 3609

If you read this file _as_is_, just ignore the funny characters you see.
It is written in the POD format (see pod/perlpod.pod) which is specially
designed to be readable as is.

=head1 NAME

README.mint - Perl version 5 on Atari MiNT

=head1 DESCRIPTION

There is a binary version of perl available from the FreeMiNT project
http://freemint.de/  You may wish to use this instead of trying to
compile yourself.

B<The following advice is from perl 5.004_02 and is probably rather
out of date.>

If you want to build perl yourself on MiNT (or maybe on an Atari without
MiNT) you may want to accept some advice from somebody who already did it...

There was a perl port for Atari ST done by ++jrb [email protected].
This port tried very hard to build on non-MiNT-systems.  For the
sake of efficiency I've left this way.  Yet, I haven't removed bammi's
patches but left them intact.  Unfortunately some of the files that
bammi contributed to the perl distribution seem to have vanished?

So, how can you distinguish my patches from bammi's patches?  All of
bammi's stuff is embedded in "#ifdef atarist" preprocessor macros.
My MiNT port uses "#ifdef __MINT__" instead (and unconditionally
undefines "atarist".  If you want to continue on bammi's port, all 
you have to do is to swap the "-D" and "-U" switches for "__MINT__"  
and "atarist" in the variable ccflags.

However, I think that my version will still run on non-MiNT-systems
provided that the user has a Eunuchs-like environment (i.e. the
standard envariables like $PATH, $HOME, ... are set, there is a
POSIX compliant shell in /bin/sh, and...)

=head1 Known problems with Perl on MiNT

The problems you may encounter when building perl on your machine
are most probably due to deficiencies in MiNT resp. the Atari
platform in general.

First of all, if you have less than 8 MB of RAM you shouldn't
even try to build Perl yourself.  Better grab a binary pre-compiled
version somewhere.  Even if you have more memory you should take
some care.  Try to run in a fresh environment (without memory
fragmented too much) with as few daemons, accessories, xcontrol
modules etc. as possible.  If you run some AES you should 
consider to start a console based environment instead.

A problem has been reported with sed.  Sed is used to create
some configuration files based on the answers you have given
to the Configure script.  Unfortunately the Perl Configure script
shows sed on MiNT its limits.  I have sed 2.05 with a stacksize
of 64k and I have encountered no problems.  If sed crashes
during your configuration process you should first try to
augment sed's stacksize:

        fixstk 64k /usr/bin/sed

(or similar).  If it still doesn't help you may have a look
which other versions of sed are installed on your system.
If you have a KGMD 1.0 installation you will find three
in /usr/bin.  Have a look there.

Perl has some "mammut" C files.  If gcc reports "internal
compiler error: program cc1 got fatal signal 10" this is very
likely due to a stack overflow in program cc1. Find cc1 
and fix its stack.  I have made good experiences with 

        fixstk 2 cc1

This doesn't establish a stack of 2 Bytes only as you might
think.  It really reserves one half of the available memory
for cc1's stack.  A setting of 1 would reserve the entire
memory for cc1, 3 would reserve three fourths.  You will have
to find out the value that suits to your system yourself.

To find out the location of the program "cc1" simply type
`gcc --print-prog-name cc1' at your shell prompt.

Now run make (maybe "make -k").  If you get a fatal signal 10 
increase cc1's stacksize, if you run out of memory you should 
either decrease the stacksize or follow some more hints:

Perl's building process is very handy on machines with a lot
of virtual memory but may result in a disaster if you are short
of memory.  If gcc fails to compile many source files you should
reduce the optimization.  Grep for "optimize" in the file
config.sh and change the flags.

If only several huge files cause problems (actually it is not a
matter of the file size resp. the amount of code but depends on
the size of the individual functions) it is useful to bypass
the make program and compile these files directly from the
command line.  For example if you got something like the
following from make:

        CCCMD = gcc -DPERL_CORE ....
        ...
        ...: virtual memory exhausted

you should hack into the shell:

        gcc -DPERL_CORE ... toke.c

Please note that you have to add the name of the source file
(here toke.c) at the end.

If none of this helps, you're helpless.  Wait for a binary
release.  If you have succeeded you may encounter another problem
at the linking process.  If gcc complains that it can't find
some libraries within the perl distribution you probably have