-
Notifications
You must be signed in to change notification settings - Fork 0
/
INSTALL
232 lines (174 loc) · 9.1 KB
/
INSTALL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
==================================================================
The short install procedure is described in README. Here is the long one:
This module was working OK with 5.003 (some time ago, newer versions
of this module might have broken this...).
If you have Net::FTP module installed and working (type
perl -MNet::FTP -le "print 'OK'"
to check, and, say
perl -MCPAN -e 'install Net::FTP'
to install it if you do not have it), then Makefile.PL may fetch and
configure GP/PARI for you, so you can skip steps a,b,c,e in the
description below. [Sometimes Net::FTP requires setting PASSIVE_FTP
environment variable.]
With Net::FTP, building, testing, and testing is done in most cases with
perl Makefile.PL
make
make test
make install
==================================================================
Let me state the obvious: Math::Pari is a Perl module, so you need to
have a "good enough" binary of Perl running on your machine.
Compiling any Perl module involves a heavy usage of the Config module
coming with Perl. If your Perl is copied from another machine with an
incompatible configuration, expect problems. [Typical syndroms:
glob failing; /usr/ucb/cc used instead of a real compiler, make trying
to run `cl' you do not have etc.]
==================================================================
GP/PARI detects the type of the assembler files needed for your
processor; Math::Pari copies this logic, but may not contain the
latest updates/improvements. If the detection-of-assembler is wrong, put
machine=assembler_type to the Makefile.PL line, as in
perl Makefile.PL machine=hppa
As the last resort, machine=none means using a portable-and-slow C code.
I would like to hear about wrong assembler-detection.
==================================================================
The older versions of Math::Pari were using GP/PARI configuration
scripts to generate the header file libPARI/paricfg.h needed for the
compile of the library. The newer version generate this file
themselves. If this new way fails, put the word Configure on the
Makefile.PL command line to generate this file "the old way":
perl Makefile.PL Configure
A typical syndrom is a compile error related to undefined CLK_TCK. I
would like to hear about these cases. In the worst cases you may need
to manually copy paricfg.h from a subdirectory of GP/PARI build
directory to libPARI/paricfg.h.
[libPARI/paricfg.h is not recreated when rerunning Makefile.PL without
the Configure options. If you need it to be recreated, rename this
file before rerunning.]
==================================================================
If the problems with Math::Pari being unable to build persist, there is
another way to build it: use a pre-build version of the PARI library. Put
the link options on the Makefile.PL command line like this:
perl Makefile.PL LIBPARI="-L/lib -lpari"
This is a non-yet-supported way to build the library; try it only if anything
else fails.
Known problems:
spoofed version;
no graphing functions present;
bad free() at t/Pari.t line 265
(calling installed Perl function from PARI)
no PARI tests to convert;
no POD to create;
no check for ep codes;
no patching the source;
[All but the first 3 of the problems can be avoided if one
lets Makefile.PL download and patch PARI, then builds the library
using the downloaded+patched version.]
Possible problems:
different sizeof(long);
non-compatible threading model;
-lpari build with different non-compatible compiler;
==================================================================
Other recognized options:
force_download Download PARI/GP even if a directory is found
paridir=PATH_TO_DIST_DIR Use the directory with Pari distribution
pari_tgz=PATH_TO_TAR_GZ To extract a local pari*.tar.gz and patch
(if needed) the resulting directory tree.
version23_ok=NUMBER If 0 (default), will skip versions 2.3.* of
PARI in automatic search (N/A if `paridir' is given).
==================================================================
Here is the manual procedure which is somewhat similar to what
Makefile.PL does.
a) Get the latest PARI distribution from
ftp://megrez.math.u-bordeaux.fr/pub/pari/unix/
b) uncompress the distribution; optionally run 'Configure' script
sh ./Configure
(Running 'Configure' is required only if you manually copy 'paricfg.h'.)
c) Math::Pari does not care whether you did `make' GP/PARI, but you can do
it nevertheless:
make test
in toplevel PARI directory;
d) uncompress the Math::Pari archive into a separate directory (for
best results make it a sibling of GP/PARI's root directory; kid
or parent should do as well);
e) _Optionally_ find the architecture of your processor (if it is not
known/supported and recognized automatically, the slower 'port' code
without assembler should be used). Recognized "processors" are
sun3 sparcv7 sparcv8micro sparcv8super alpha hppa i386 port
(many more for v2.3.0 and later) the current version should
autorecognize them in most situations;
f) do (assuming your architecture is hppa)
perl Makefile.PL
or
perl Makefile.PL machine=hppa
You may also want to add Configure argument (see above). At this
moment you may want to manually copy paricfg.h if all the rest fails...)
This step autogenerates many files, such as POD documentation of GP/PARI
and the module test suite, from the GP/PARI distribution.
g) then
make
make test
h) Now
make install
should make this extension available to the perl programs.
x) Patches to some versions of GP/PARI may be needed (in `patches11',
or 'patch12', etc. depending on the version of GP/PARI 2.*.*).
This may be done automatically during auto-download of GP/PARI.
x) We skip "compatibility" tests, and do not support "compatibility" mode
(with very old versions of GP/PARI).
x) dmake on Win32 is buggy. The symptom is a message about not being
able to find the target 'all'. The workaround is to run `dmake
-i'. One must watch for errors (with "Ignored" in the error
message), since in this regime dmake won't stop on an error.
=======================================================
Here are the typical failure modes of the tests:
t/00_Pari.t:109 A bug in REx engine on Perl 5.6.0
(now skipped under 5.6.0)
Segfault in t/nfields.t:21 Too short a stack for Perl process (very
long REx is running to test whether this
test succeeds). Try something like this (csh)
limit stacksize 8192
=======================================================
Sometimes the server ftp://megrez.math.u-bordeaux.fr/pub/pari/unix/
goes off line for a couple of days (mostly in August). Then you can try
downloading from some mirror: google, e.g., for pari-2.1.7.tgz.
=======================================================
KNOWN PROBLEMS:
Darwin and other systems where -fno-common gcc flag is used:
*) Remove the flag from libPARI/Makefile macro CCFLAGS;
*) rm libPARI/*.o
*) make
The symptom: _hiremainder _overflow are reported to be multiply defined.
Try applying the patch in patches/diff_2.1.6_no-common (we apply it
automatically on Darwin if auto-patching is used).
=======================================================
If you get problems with `overflow' and `hiremainder' symbols not defined:
there may be (at least) two reasons:
a) Your Perl is not built on "this machine", so its %Config{} hash
does not reflect the real configuration of this machine;
b) Generation of kernel*.o files (or whatever the object file extension is
on your system) is wrong: either Math::Pari build process is out of sync
with the GP/PARI one, or Math::Pari::Build is just plain buggy.
c) Additinally, this is may be a problem with "an older version" of GP/PARI;
giving option
version23_ok=1
to Makefile.PL would allow it to search for newer versions of GP/PARI
(going to "fresh install directory" may be needed).
If you are completely sure that "a", "c" are not applicable, you can do the
following to help in fixing this problem:
a) Build GP/PARI (it is not necessary to install it); redirect the output
of build process to a file. (You may need to set CC=cc_compiler_of_perl
in environment since GP/PARI may prefer gcc otherwise.)
b) Run `nm' on kernel*.o in libPARI and in the GP/PARI architecture-specific
directory (names of object files may differ slightly, as in digits
appended). The intent of Math::Pari::Build is to have "the same
reports" generated. At least `overflow' and `hiremainder' should
appear with same number of underscores (0 or 1) prepended, and with
the same "class type" letter before them.
c) If outputs of `nm' in "b" differ, you found a bug. Inspect the
files with redirected output of build processes of Math::Pari, and find
how kernel*.o files were built (including how the intermediate files -
such as kernel1.s - are built). Note the differences.
If the information in "b" and "c" is enough for you to fix Math::Pari::Build,
do so; please report your fix. Otherwise just report the discrepancies of "b"
and "c". A lot of thanks!!!