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 implmentation 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 librararies).

    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@bevo.che.wisc.edu
University of Wisconsin-Madison
Department of Chemical & Biological Engineering

Last updated: Wed Dec 17 15:17:29 2003