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 |
---|