Mercurial > hg > octave-nkf
annotate README.Cray @ 9585:06b8b51dca48
also handle user-defined graphics properties in new property name validation scheme
| author | John W. Eaton <jwe@octave.org> |
|---|---|
| date | Fri, 28 Aug 2009 18:37:31 -0400 |
| parents | 66fdc831c580 |
| children |
| rev | line source |
|---|---|
| 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 | |
|
9031
1052a66078cf
Documentation cleanup of top-level Octave directory (READMEs, INSTALL)
Rik <rdrider0-list@yahoo.com>
parents:
7088
diff
changeset
|
15 lapack implementation in Fortran and to not require the readline |
| 4680 | 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 | |
|
9031
1052a66078cf
Documentation cleanup of top-level Octave directory (READMEs, INSTALL)
Rik <rdrider0-list@yahoo.com>
parents:
7088
diff
changeset
|
21 with the Cray libraries). |
| 4680 | 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 | |
| 9322 | 148 jwe@octave.org |
| 4680 | 149 |
| 7088 | 150 Last updated: Wed Dec 17 15:17:29 2003 |