I have ported octave-1.0 to SCO-3.2.4, a i386/i486 SYSVR3 system.
Bellow is a sumary of the needed changes.
I can send a diff, if you want to, and binaries.
( Only next year, please...)
Unfortunatelly the SCO system dont have NaN, Inf, etc, so the bsd-math have
to be use, with strange results, Inf-Inf = 0, etc...
I will look for a correct math lib in the future.
I have in the same hardware a DOS partions, and MATLAB-4.0 for Windows.
Matlab is faster than octave, the first and second bench demo of
Matlab runs 4 to 8 times faster and much faster during
interpretation of m-files, namely for loops, and perhaps memory
******* LIBG++-2.5.3 and gcc-2.5.8
+ No problems! make check run OK on libg++, make compare also on gcc.
GNU guys are the best!
default except for an added #undef i386
( I don't think this is needed)
+ compiled with CFLAGS=-O3
+ ./src/makefile modified to merge libI77.a and libF77.a into libf2c.a
+ some minor non-logued changes made to the makefiles and sources
+ in ./src, main.o is't compiled because of VPATH points to
a directory with a main.o...
comment VPATH during compilation in this directory.
+ <math.h> ! yes, the system's header file.
confliting abs() and sqr(). Those lines in <math.h> comented out!
Also in /usr/local/lib/gcc....../include/math.h.
SCO defines abs() sqr() for c++ in math.h. libg++ has provisions
to circunvent this, but octave no.
Recompiled ALL after this,
gcc, (not needed ...)
libg++ (after commenting the circunvents)
, f2c, octave.
libmalloc.a came from bash-1.14 after defining USG and correcting a
declaration of mcheck in malloc.h .
-lmalloc avoids runtime error message "New: Virtual memory exceded"
( This message cames from a gcc builtin compiled function! This
indicates that gcc shoulded be linked with a gnu malloc!)
(read the gcc info, External Bugs, and Installation i386-*-sco)
strftime() and ctflow() only exists in ansi and posix libraries.
added SCOOBJ objects and rules to extract objects from libraries.
(can backpage through a pipe)
( I think that no precision is lost, because the Fortran functions
are internally computed as REAL, and several float->double->float
convertions are avoided. I am correct ??)
+ ./config.status RANLIB=true
if the Xenix cross developement is installed, ranlib exists,
although is gives an error on the Unix COFF files.
added "&& !defined(i386)" to "#if defined (FD_SET)"
to avoid inclusion of <sys/times.h>, because timeval was already
#if defined (HAVE_TERMIOS_H)
#if !defined (M_XENIX) || defined (M_UNIX)
" || defined (M_UNIX)" added, to cause inclusion of <sys/stream.h>
M_XENIX is wrongly defined in gcc (perhaps beacause of the existence
of the xenix cross development).
changed the term_invbeg and term_invend to "so" and "se" to enable
inverse-video. Probably other definitions are also incorrect for SCO.
+ isnan exists, but I can't generate a NaN...
Can NaN be generated in a 387 or 486? The default in SCO/387 is to
round to the nearest number, so, even if I hack a NaN into a double,
I get it converted to Inf (???).
+ I have also sucessefuly compiled octave-1.0 under posix source,
giving the "-posix" flag to gcc, g++.
However, the info and readline directories need to many rework.
+ I can't compile c++ with debugging (-g) enabled!
The system assembler gives error. However, all libg++ sources was
compiled this way!!!
+ There are problems with some bsd-math functions.
gcc warns about floating point error in logb.c log1p.c and scalb.c.
I supose that the idea is to generate floating point exception at
run time, so I compiled them with no optimization. I don't know
what gcc does in the other case.