Mi splgn s gnin.g
[perl.git] / README.mint
1 ##########################################################################
2 # *** README.mint
3 ##########################################################################
4
5 If you want to build perl yourself on MiNT (or maybe on an Atari without
6 MiNT) you may want to accept some advice from somebody who already did it...
7
8 There was a perl port for Atari ST done by ++jrb bammi@cadence.com.
9 This port tried very hard to build on non-MiNT-systems.  For the
10 sake of efficiency I've left this way.  Yet, I haven't removed bammi's
11 patches but left them intact.  Unfortunately some of the files that
12 bammi contributed to the perl distribution seem to have vanished?
13
14 So, how can you distinguish my patches from bammi's patches?  All of
15 bammi's stuff is embedded in "#ifdef atarist" preprocessor macros.
16 My MiNT port uses "#ifdef __MINT__" instead (and unconditionally
17 undefines "atarist".  If you want to continue on bammi's port, all 
18 you have to do is to swap the "-D" and "-U" switches for "__MINT__"  
19 and "atarist" in the variable ccflags.
20
21 However, I think that my version will still run on non-MiNT-systems
22 provided that the user has a Eunuchs-like environment (i.e. the
23 standard envariables like $PATH, $HOME, ... are set, there is a
24 POSIX compliant shell in /bin/sh, and...)
25
26 Known problems
27 ==============
28
29 The problems you may encounter when building perl on your machine
30 are most probably due to deficiencies in MiNT resp. the Atari
31 platform in general.
32
33 First of all, if you have less than 8 MB of RAM you shouldn't
34 even try to build Perl yourself.  Better grab a binary pre-compiled
35 version somewhere.  Even if you have more memory you should take
36 some care.  Try to run in a fresh environment (without memory
37 fragmented too much) with as few daemons, accessories, xcontrol
38 modules etc. as possible.  If you run some AES you should 
39 consider to start a console based environment instead.
40
41 A problem has been reported with sed.  Sed is used to create
42 some configuration files based on the answers you have given
43 to the Configure script.  Unfortunately the Perl Configure script
44 shows sed on MiNT its limits.  I have sed 2.05 with a stacksize
45 of 64k and I have encountered no problems.  If sed crashes
46 during your configuration process you should first try to
47 augment sed's stacksize:
48
49         fixstk 64k /usr/bin/sed
50
51 (or similar).  If it still doesn't help you may have a look
52 which other versions of sed are installed on your system.
53 If you have a KGMD 1.0 installation you will find three
54 in /usr/bin.  Have a look there.
55
56 Perl has some "mammut" C files.  If gcc reports "internal
57 compiler error: program cc1 got fatal signal 10" this is very
58 likely due to a stack overflow in program cc1. Find cc1 
59 and fix its stack.  I have made good experiences with 
60
61         fixstk 2 cc1
62
63 This doesn't establish a stack of 2 Bytes only as you might
64 think.  It really reserves one half of the available memory
65 for cc1's stack.  A setting of 1 would reserve the entire
66 memory for cc1, 3 would reserve three fourths.  You will have
67 to find out the value that suits to your system yourself.
68
69 To find out the location of the program `cc1' simply type
70 `gcc --print-prog-name cc1' at your shell prompt.
71
72 Now run make (maybe "make -k").  If you get a fatal signal 10 
73 increase cc1's stacksize, if you run out of memory you should 
74 either decrease the stacksize or follow some more hints:
75
76 Perl's building process is very handy on machines with a lot
77 of virtual memory but may result in a desaster if you are short
78 of memory.  If gcc fails to compile many source files you should
79 reduce the optimization.  Grep for "optimize" in the file
80 config.sh and change the flags.
81
82 If only several huge files cause problems (actually it is not a
83 matter of the file size resp. the amount of code but depends on
84 the size of the individual funtions) it is useful to bypass
85 the make program and compile these files directly from the
86 command line.  For example if you got something like the
87 following from make:
88
89         CCCMD = gcc -DPERL_CORE ....
90         ...
91         ...: virtual memory exhausted
92
93 you should hack into the shell:
94
95         gcc -DPERL_CORE ... toke.c
96
97 Please note that you have to add the name of the source file
98 (here toke.c) at the end.
99
100 If none of this helps, you're helpless.  Wait for a binary
101 release.  If you have succeded you may encounter another problem
102 at the linking process.  If gcc complains that it can't find
103 some libraries within the perl distribution you probably have
104 an old linker.  If it complains for example about "file not
105 found for xxx.olb" you should cd into the directory in
106 question and
107
108         ln -s libxxx.a xxx.olb
109
110 This will fix the problem.
111
112 This version (5.00402) of perl has passed most of the tests on my system:
113
114 Failed Test  Status Wstat Total Fail  Failed  List of failed
115 ------------------------------------------------------------------------------
116 io/pipe.t                    10    2  20.00%  7, 9
117 io/tell.t                    13    1   7.69%  12
118 lib/complex.t               762   13   1.71%  84-85, 248-251, 257, 272-273,
119                                               371, 380, 419-420
120 lib/io_pipe.t                10    1  10.00%  9
121 lib/io_tell.t                13    1   7.69%  12
122 op/magic.t                   30    2   6.67%  29-30
123 Failed 6/152 test scripts, 96.05% okay. 20/4359 subtests failed, 99.54% okay.
124
125 Pipes always cause problems with MiNT, it's actually a surprise that
126 most of the tests did work.  I've got no idea why the "tell" test failed,
127 this shouldn't mean too big a problem however.
128
129 Most of the failures of lib/complex seem to be harmless, actually errors
130 far right to the decimal point...  Two failures seem to be serious:
131 The sign of the results is reversed.  I would say that this is due
132 to minor bugs in the portable math lib that I compiled perl with.
133
134 I haven't bothered very much to find the reason for the failures
135 with op/magic.t and op/stat.t.  Maybe you'll find it out.
136
137 ##########################################################################
138
139 Another possible problem may arise from the implementation of  the "pwd" 
140 command.  It happened to add a carriage return and newline to its output 
141 no matter what the setting of $UNIXMODE is.  This is quite annoying since many
142 library modules for perl take the output of pwd, chop off the
143 trailing newline character and then expect to see a valid path in
144 that.  But the carriage return (last but second character!) isn't
145 chopped off.  You can either try to patch all library modules (at
146 the price of performance for the extra transformation) or you can
147 use my version of pwd that doesn't suffer from this deficiency.
148
149 The fixed implementation is in the mint subdirectory.  Running
150 "Configure" will attempt to build and install it if necessary
151 (hints/mint.sh will do this work) but you can build and install it
152 explicitly by:
153
154         cd mint
155         make install
156
157 This is the fastest solution.
158
159 Just in case you want to go the hard way: perl won't even build with a
160 broken pwd!  You will have to fix the library modules
161 (ext/POSIX/POSIX.pm, lib/Cwd.pm, lib/pwd.pl) at last after building
162 miniperl.
163
164 A major nuisance of current MiNTLib versions is the implementation
165 of system() which is far from being POSIX compliant.  A real system()
166 should fork and then exec /bin/sh with its argument as a command
167 line to the shell.  The MiNTLib system() however doesn't expect
168 that every user has a POSIX shell in /bin/sh.  It tries to work
169 around the problem by forking and exec'ing the first token in its argument
170 string.  To get a little bit of compliance to POSIX system() it
171 tries to handle at least redirection ("<" or ">") on its own 
172 behalf.  
173
174 This isn't a good idea since many programs expect that they can
175 pass a command line to system() that exploits all features of a
176 POSIX shell.  If you use the MiNTLib version of system() with
177 perl the Perl function system() will suffer from the same deficiencies.
178
179 You will find a fixed version of system() in the mint subdirectory.
180 You can easily insert this version into your system libc:
181
182         cd mint
183         make system.o
184         ar r /usr/lib/libc.a
185         ranlib /usr/lib/libc.a
186
187 If you are suspicious you should either back up your libc before
188 or extract the original system.o from your libc with 
189 "ar x /usr/lib/libc.a system.o".  You can then backup the system.o
190 module somewhere before you succeed.
191
192 Anything missing?  Yep, I've almost forgotten...  
193 No file in this  distribution without a fine saying.  Take this one:
194
195         "From a thief you should learn: (1) to work at night;
196         (2) if one cannot gain what one wants in one night to
197         try again the next night; (3) to love one's coworkers
198         just as thieves love each other; (4) to be willing to
199         risk one's life even for a little thing; (5) not to 
200         attach too much value to things even though one has 
201         risked one's life for them - just as a thief will resell
202         a stolen article for a fraction of its real value; 
203         (6) to withstand all kinds of beatings and tortures
204         but to remain what you are; and (7) to believe your
205         work is worthwhile and not be willing to change it."
206
207                         -- Rabbi Dov Baer, Maggid of Mezeritch
208
209 OK, this was my motto while working on Perl for MiNT, especially rule (1)...
210
211 Have fun with Perl!
212
213 Guido Flohr
214 --
215 mailto:gufl0000@stud.uni-sb.de
216 http://stud.uni-sb.de/~gufl0000