|
4680
|
1 It should now be possible to compile and link Octave on the Cray SV1 |
|
|
2 and perhaps other similar Cray systems using the following procedure. |
|
|
3 It even runs and seems to work, at least for the few small things I |
|
|
4 tried. |
|
|
5 |
|
|
6 * Run |
|
|
7 |
|
|
8 configure \ |
|
|
9 F77=ftn FFLAGS="-dp -O0" \ |
|
|
10 CC=cc CFLAGS=-O0 CXX=CC \ |
|
|
11 CXXFLAGS="-O0 -h new_for_init -h nomessage=76" \ |
|
|
12 --without-blas --without-lapack --disable-readline |
|
|
13 |
|
|
14 The last to arguments tell Octave to use the reference blas and |
|
|
15 lapack implmentation in Fortran and to not require the readline |
|
|
16 library. If you have the readline library, you can omit the last |
|
|
17 option. You can also try to use a vendor library for LAPACK and |
|
|
18 BLAS, but how are those compiled? You will need a version of the |
|
|
19 library that is compiled for 64-bit double precision values, but |
|
|
20 that uses the D and Z names (I'm not sure that this is the case |
|
|
21 with the Cray librararies). |
|
|
22 |
|
|
23 I'm using -O0 in an effort to speed up compilation. If you want |
|
|
24 an optimized version and have time to wait for the build to |
|
|
25 complete, then use whatever -On option you like. |
|
|
26 |
|
|
27 * Edit the generated Makeconf file and make sure that you have |
|
|
28 |
|
|
29 FFLAGS = -dp -O0 |
|
|
30 CFLAGS = -O0 |
|
|
31 CXXFLAGS = -O0 -h new_for_init -h nomessage=76 |
|
|
32 FPICFLAG = |
|
|
33 CPICFLAG = |
|
|
34 CXXPICFLAG = |
|
|
35 |
|
|
36 The first three should be handled automatically by the configure |
|
|
37 arguments, but the others are not (yet). |
|
|
38 |
|
|
39 * Edit liboctave/data-conv.h and force the definitions of |
|
|
40 TWO_BYTE_INT and FOUR_BYTE_INT to be int. These will have to be |
|
|
41 fixed correctly later, but this fix will allow Octave to compile |
|
|
42 and even run, though some things like saving and loading data with |
|
|
43 some binary file formats will be broken. Suggestions for a good |
|
|
44 way to fix this are welcome. |
|
|
45 |
|
|
46 * If building from CVS, you will need to have gperf installed, or |
|
|
47 you can generate src/oct-gperf.h on some other machine and copy to |
|
|
48 the src subdirectory in the Cray build tree. |
|
|
49 |
|
|
50 * If you don't have TeX installed on your SV1, then edit the |
|
|
51 generated octMakefile and remove doc from the SUBDIRS variable so |
|
|
52 you won't try to run make in the doc subdirectory. Otherwise, it |
|
|
53 will fail because you don't have TeX installed (and why would |
|
|
54 you?). This is only a problem when building from CVS or if you |
|
|
55 build from a distribution and configure with something other than |
|
|
56 --prefix=/usr/local. |
|
|
57 |
|
|
58 * Run |
|
|
59 |
|
|
60 gmake -k omit_deps=true |
|
|
61 |
|
|
62 and it should run all the way to creating an octave executable |
|
|
63 (see below for why omit_deps=true is needed). |
|
|
64 |
|
|
65 |
|
|
66 REMAINING PROBLEMS |
|
|
67 ------------------ |
|
|
68 |
|
|
69 * I tried to get dependency generation to work, but it seems there is |
|
|
70 a bug in the C++ compiler because it keeps crashing with errors like |
|
|
71 this: |
|
|
72 |
|
|
73 making pathsearch.d from pathsearch.cc |
|
|
74 CC-1353 CC: INTERNAL File = CColVector.cc, Line = 38 |
|
|
75 |
|
|
76 #include "oct-cmplx.h" |
|
|
77 ^ |
|
|
78 |
|
|
79 CC-2202 CC: ERROR |
|
|
80 "/opt/ctl/CC_sv1/CC_sv1/lib/ccom" (pid 69504) was terminated |
|
|
81 due to receipt of signal 06: Abort (core dumped). |
|
|
82 |
|
|
83 when I try to use the -M option. Dependency generation is |
|
|
84 relatively slow, so maybe it would be worth trying to speed it up |
|
|
85 by using a simpler tool. We are currently using the compilers to |
|
|
86 build lists of dependencies that include system header files, but |
|
|
87 maybe it would be good enough if we only listed the header files |
|
|
88 that are included with the Octave sources. In that case, we could |
|
|
89 probably write a simple script that could do the job and that |
|
|
90 could run much faster than the compiler. |
|
|
91 |
|
|
92 * IEEE Inf and NaN (and Octave's NA value, which is a particular NaN |
|
|
93 value) are all currently set to DBL_MAX since the SV1 doesn't |
|
|
94 support IEEE floating point numbers. Will this be true of future |
|
|
95 machines from Cray? I don't think it is possible to have a fully |
|
|
96 functional version of Octave (or Matlab) on a system without IEEE |
|
|
97 numbers. |
|
|
98 |
|
|
99 * TWO_BYTE_INT and FOUR_BYTE_INT types, mostly used in load-save.cc. |
|
|
100 This can probably be solved by using arrays of char values and |
|
|
101 some masking, but it will probably be a bit tricky. The problem |
|
|
102 is that various binary data file formats are specified using |
|
|
103 integer values of specific sizes, so we need to be able to read |
|
|
104 and write integer values in 16 and 32 bit formats. |
|
|
105 |
|
|
106 * The code in liboctave/mach-info.cc that determines the floating |
|
|
107 point format used by the system assumes that a double is exactly |
|
|
108 twice as wide as an int. This should be fixed, since the Cray has |
|
|
109 |
|
|
110 sizeof (char) == 1 |
|
|
111 sizeof (short) == 8 |
|
|
112 sizeof (int) == 8 |
|
|
113 sizeof (long) == 8 |
|
|
114 sizeof (double) == 8 |
|
|
115 |
|
|
116 For now, I forced the floating point format based on an #ifdef CRAY. |
|
|
117 |
|
|
118 * Build a working readline library. Probably not too hard but I |
|
|
119 didn't think it was worth the effort yet. I can't run Octave |
|
|
120 interactively on the SV1 I have access to anyway, so command line |
|
|
121 editing doesn't matter much. |
|
|
122 |
|
|
123 * Build the FFTW library for better fft performance. Without this, |
|
|
124 we still have fft and ifft functions using FFTPACK. |
|
|
125 |
|
|
126 * Build the HDF5 library to support loading and saving of HDF |
|
|
127 files. This is not necessary unless you need to access Octave |
|
|
128 data files that have been stored in the HDF file format. |
|
|
129 |
|
|
130 * Link with fast BLAS and LAPACK libraries for better performance. |
|
|
131 There is a Cray library, but I'm not sure whether we can use it |
|
|
132 directly. Does DGEMM in the Cray BLAS library use double |
|
|
133 precision, or is it compiled with the equivalent of -dp? If it |
|
|
134 uses double precision (i.e., 128-bit floating point values) then |
|
|
135 it will take some work to make this functional for Octave, since |
|
|
136 Octave uses the D and Z names and we would presumably need the S |
|
|
137 and C names instead. |
|
|
138 |
|
|
139 * Shared libraries. Apparently this is not supported on the SV1, so |
|
|
140 dynamically linked functions (.oct files) will not work on this |
|
|
141 system. |
|
|
142 |
|
|
143 * There are a few warnings when compiling glob/glob.c that should |
|
|
144 probably be fixed. |
|
|
145 |
|
|
146 |
|
|
147 John W. Eaton |
|
|
148 jwe@bevo.che.wisc.edu |
|
|
149 University of Wisconsin-Madison |
|
7088
|
150 Department of Chemical & Biological Engineering |
|
4680
|
151 |
|
7088
|
152 Last updated: Wed Dec 17 15:17:29 2003 |
