From bug-octave-request at bevo dot che dot wisc dot edu  Thu Jan  8 17:18:29 1998
Subject: RH 5.0 alpha: Partial success
From: Peter Speier <speier at sugar-land dot spc dot slb dot com>
To: bug-octave at bevo dot che dot wisc dot edu
Date: Thu, 08 Jan 1998 17:22:00 -0500

Thanks to the distributed knowledge of the linux community on the net
I finally got octave compiled and sufficiently running for me under
RH5.0
on alpha.

The recipe I used:
1) installing egcs1.0 with the patches egcs-1.0.diff and 
libg++2.8.0b6.5.tar.gz by (H.J.Lu ftp://ftp.yggdrasil.com/private/hjl) 
as suggested by D.A. Gilbert on axp-list at redhat dot com dot 

The patches fix the problem of "the stdc++ and glibc 
both having (incompatible??) versions of libio", that prevented octave 
to compile under RH5.0/alpha's standard compiler.
I installed egcs as second compiler using the recommended bootstrap 
installation.

2) getting the octave-2.09.95 prerelease package.
(The official 2.09 version did not allow new friend template decl of
egcs; 
 enforcing the old behaviour failed in the link stage.)

3)configuring octave with
FFLAGS='-O3 -mieee' CFLAGS='-g -O3 -mcpu=21164 -Wall -mieee'
CXXFLAGS='-mcpu=21164 -fno-implicit-templates -g -O3 -Wall -mieee'
./configure

The -miee flag had to be given by hand to enforce IEEE fp exception
handling.

4) Compiling
Everything worked well except the Fortran compiler that could not
compile
the following files in libcruft with the chosen optimization.
So these were compiled by hand with lower optimization:

g77 -c -O -mieee zher2k.f
g77 -c -O -mieee zherk.f
g77 -c -O -mieee zhetd2.f (g77 does not return)
g77 -c -O -mieee zlahqr.f
g77 -c -O -mieee zlarfg.f
g77 -c -O -mieee zlarfx.f
g77 -c -O -mieee zlartg.f
g77 -c -O -mieee zlatrd.f
g77 -c -O -mieee ztrsyl.f


All Fortran errors were of type:

zher2k.f: In subroutine `zher2k':
zher2k.f:368: internal error--unrecognizable insn:
(insn 1367 1458 1433 (clobber (mem:TI (plus:DI (reg:DI 30 $30)
                (const_int 408)))) -1 (insn_list:REG_DEP_ANTI 1388
(insn_list:REG_DEP_ANTI 1402 (insn_list:REG_DEP_ANTI 1444
(insn_list:REG_DEP_ANTI 1458 (nil)))))
    (nil))
g77: Internal compiler error: program f771 got fatal signal 6

zlatrd.f: In subroutine `zlatrd':
zlatrd.f:276: internal error--unrecognizable insn:
(insn:QI 1199 1214 2788 (clobber (mem/s:TI (plus:DI (reg:DI 30 $30)
                (const_int 224)))) -1 (insn_list 1176 (nil))
    (nil))



There were also a lot of warning of the type:

Array.h:187: warning: `class Array<int> * this' might be used
uninitialized in this function
Array.h:187: warning: variable `class Array<int> * this' might be
clobbered by `longjmp' or `vfork'

and

dassl.cc:248: warning: assuming & on
`DASSL_options::set_absolute_tolerance(double)'
../liboctave/Array2.h:145: warning: variable `int i' might be clobbered
by `longjmp' or `vfork'

-----------------------------

For my use the libraries and the interpreter works well enough,
including
gplot and image().
However not everything is perfect: The following example fail for large
k, 
depending on the previous input, eg. k=100 fails, k=10 is ok.

octave:1> i = 1:k;
octave:2> j = 1:k;
octave:3> i'/j';

Program received signal SIGSEGV, Segmentation fault.
0x120795d20 in dgemm_ ()
Current language:  auto; currently fortran
(gdb) bt
#0  0x120795d20 in dgemm_ ()
#1  0x120729458 in dgelss_ ()
#2  0x12069cb18 in Matrix::lssolve (this=0x1fffe8f8, b=Invalid F77 type
code 17 in symbol table.
) at dMatrix.cc:1165
#3  0x12044913c in xdiv (a=Invalid F77 type code 17 in symbol table.
) at xdiv.cc:131
#4  0x1203d7ba8 in div (a1=Invalid F77 type code 17 in symbol table.
) at op-m-m.cc:71
#5  0x1203434b4 in do_binary_op (op=Invalid F77 type code 5 in symbol
table.
) at ov.cc:711
#6  0x120274c40 in tree_binary_expression::eval (this=0x20aa50c0)
    at pt-exp.cc:432
#7  0x120276430 in tree_simple_assignment_expression::eval
(this=0x20aa5010, 
    print=Logicals of length 8 bytes not supported
) at pt-exp.cc:711
#8  0x12029c3c8 in tree_statement_list::eval (this=0x20aa1d20,
print=Logicals of length 8 bytes not supported
)
    at pt-misc.cc:131
#9  0x1202f9b90 in main_loop () at toplev.cc:285
#10 0x12000b7e0 in main (argc=1, argv=0x1ffff8d0) at octave.cc:612




Peter Speier


---------------------------------

P.S.:   In the last mail I wrote, that  xv does not work with the
osf-binary.
        The problem is more global: the interpreter function system()
function
	 does not work. It always returns 127.
	(man system: "The value returned is 127 if the execve() call for 
	 /bin/sh fails"...)  Is that to be expected from a osf-binary? Then why
does 	        gnuplot work?

octave.bin:1> system("/bin/ls")
ans = 127
octave.bin:2>