Mercurial > hg > octave-lojdl

comparison README.Cray @ 4680:493ff0643644

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
[project @ 2003-12-17 21:18:18 by jwe]
author jwe
date Wed, 17 Dec 2003 21:18:18 +0000
parents
children 5eb3db6e4042
comparison
equal deleted inserted replaced
4679:c0302db81b75 4680:493ff0643644
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
150 Chemical & Biological Engineering Department
151
152 Wed Dec 17 15:17:29 2003