From bug-octave-request at bevo dot che dot wisc dot edu  Fri Dec 12 10:10:28 1997
Subject: [Re:] immediate coredump on RH5.0 alpha 
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: Fri, 12 Dec 1997 10:14:14 -0500

Hi John,

I tried to follow your advice to link octave manually.

Unfortunately also the dynamically linked binary w/o lg++ coredumps
immediately when
reaching the first "cout<<" statement.

Linking static does not succeed but results in:

ld -m elf64alpha -G 8 -O3 -static -o octave -u MAIN__ /usr/lib/crt1.o
/usr/lib/crti.o /usr/lib/crtbegin.o -L.. -L../liboctave -L../libcruft
-L../readline -L../kpathsea -L../glob -L../dlfcn -L.
-L/usr/lib/gcc-lib/alpha-redhat-linux/2.7.2.3 octave.o builtins.o
balance.o chol.o colloc.o dassl.o det.o eig.o expm.o fft.o fft2.o
filter.o find.o fsolve.o getgrent.o getpwent.o getrusage.o givens.o
hess.o ifft.o ifft2.o inv.o log.o lpsolve.o lsode.o lu.o minmax.o pinv.o

qr.o quad.o qzval.o rand.o schur.o sort.o svd.o syl.o time.o -loctinterp

-loctave -ltinst -lcruft -lOctaveReadline -lkpathsea -lglob -lf2c
-lncurses -ldl -lstdc++ -lm -lgcc -lc -lgcc /usr/lib/crtend.o
/usr/lib/crtn.o
/usr/lib/libc.a(iofclose.o): In function `_IO_fclose':
/usr/src/bs/BUILD/glibc-2.0.5/libio/iofclose.c:33: multiple definition
of `_IO_fclose'
/usr/lib/libstdc++.a(iofclose.o):/usr/src/bs/BUILD/libg++-2.7.2/libio/iofclose.c:33:

first defined here
...

This looks to me like a conflict between libc and libstdc++.

I sent this question to the RH-axp list, maybe they know about it.

There is a RPM package of octave 2.0.9 on the RH ftp server, that
patches the configure
scripts for RH5.0, but it did not change the situation.

Another thing:
In the file liboctave/lo-ieee.cc the testing for "linux" in line 76 must
be moved
before the test for "__alpha__". Otherwise the undefined DINFINITY is
used, not HUGE_VAL.


Peter Speier