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