It should now be possible to compile and link Octave on the Cray SV1 and perhaps other similar Cray systems using the following procedure. It even runs and seems to work, at least for the few small things I tried. * Run configure \ F77=ftn FFLAGS="-dp -O0" \ CC=cc CFLAGS=-O0 CXX=CC \ CXXFLAGS="-O0 -h new_for_init -h nomessage=76" \ --without-blas --without-lapack --disable-readline The last to arguments tell Octave to use the reference blas and lapack implementation in Fortran and to not require the readline library. If you have the readline library, you can omit the last option. You can also try to use a vendor library for LAPACK and BLAS, but how are those compiled? You will need a version of the library that is compiled for 64-bit double precision values, but that uses the D and Z names (I'm not sure that this is the case with the Cray libraries). I'm using -O0 in an effort to speed up compilation. If you want an optimized version and have time to wait for the build to complete, then use whatever -On option you like. * Edit the generated Makeconf file and make sure that you have FFLAGS = -dp -O0 CFLAGS = -O0 CXXFLAGS = -O0 -h new_for_init -h nomessage=76 FPICFLAG = CPICFLAG = CXXPICFLAG = The first three should be handled automatically by the configure arguments, but the others are not (yet). * Edit liboctave/data-conv.h and force the definitions of TWO_BYTE_INT and FOUR_BYTE_INT to be int. These will have to be fixed correctly later, but this fix will allow Octave to compile and even run, though some things like saving and loading data with some binary file formats will be broken. Suggestions for a good way to fix this are welcome. * If building from CVS, you will need to have gperf installed, or you can generate src/oct-gperf.h on some other machine and copy to the src subdirectory in the Cray build tree. * If you don't have TeX installed on your SV1, then edit the generated octMakefile and remove doc from the SUBDIRS variable so you won't try to run make in the doc subdirectory. Otherwise, it will fail because you don't have TeX installed (and why would you?). This is only a problem when building from CVS or if you build from a distribution and configure with something other than --prefix=/usr/local. * Run gmake -k omit_deps=true and it should run all the way to creating an octave executable (see below for why omit_deps=true is needed). REMAINING PROBLEMS ------------------ * I tried to get dependency generation to work, but it seems there is a bug in the C++ compiler because it keeps crashing with errors like this: making pathsearch.d from pathsearch.cc CC-1353 CC: INTERNAL File = CColVector.cc, Line = 38 #include "oct-cmplx.h" ^ CC-2202 CC: ERROR "/opt/ctl/CC_sv1/CC_sv1/lib/ccom" (pid 69504) was terminated due to receipt of signal 06: Abort (core dumped). when I try to use the -M option. Dependency generation is relatively slow, so maybe it would be worth trying to speed it up by using a simpler tool. We are currently using the compilers to build lists of dependencies that include system header files, but maybe it would be good enough if we only listed the header files that are included with the Octave sources. In that case, we could probably write a simple script that could do the job and that could run much faster than the compiler. * IEEE Inf and NaN (and Octave's NA value, which is a particular NaN value) are all currently set to DBL_MAX since the SV1 doesn't support IEEE floating point numbers. Will this be true of future machines from Cray? I don't think it is possible to have a fully functional version of Octave (or Matlab) on a system without IEEE numbers. * TWO_BYTE_INT and FOUR_BYTE_INT types, mostly used in load-save.cc. This can probably be solved by using arrays of char values and some masking, but it will probably be a bit tricky. The problem is that various binary data file formats are specified using integer values of specific sizes, so we need to be able to read and write integer values in 16 and 32 bit formats. * The code in liboctave/mach-info.cc that determines the floating point format used by the system assumes that a double is exactly twice as wide as an int. This should be fixed, since the Cray has sizeof (char) == 1 sizeof (short) == 8 sizeof (int) == 8 sizeof (long) == 8 sizeof (double) == 8 For now, I forced the floating point format based on an #ifdef CRAY. * Build a working readline library. Probably not too hard but I didn't think it was worth the effort yet. I can't run Octave interactively on the SV1 I have access to anyway, so command line editing doesn't matter much. * Build the FFTW library for better fft performance. Without this, we still have fft and ifft functions using FFTPACK. * Build the HDF5 library to support loading and saving of HDF files. This is not necessary unless you need to access Octave data files that have been stored in the HDF file format. * Link with fast BLAS and LAPACK libraries for better performance. There is a Cray library, but I'm not sure whether we can use it directly. Does DGEMM in the Cray BLAS library use double precision, or is it compiled with the equivalent of -dp? If it uses double precision (i.e., 128-bit floating point values) then it will take some work to make this functional for Octave, since Octave uses the D and Z names and we would presumably need the S and C names instead. * Shared libraries. Apparently this is not supported on the SV1, so dynamically linked functions (.oct files) will not work on this system. * There are a few warnings when compiling glob/glob.c that should probably be fixed. John W. Eaton jwe@octave.org Last updated: Wed Dec 17 15:17:29 2003