fatal errors running octave 2.09 under Irix6.2 (in libcruft.so?)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

fatal errors running octave 2.09 under Irix6.2 (in libcruft.so?)

Jonathan King-3
I managed to convince some of the people working at a local
functional MRI center that Octave would be mega-helpful for them,
and since it was less expensive than Matlab (:-)) they took me up on
it, even though I'm not a sysadmin type.

No sweat, I thought.

But this is Irix6.2, so it took me the better part of two days to
get a working gcc2.7.2.2 and libg++ (binaries from
http://reality.sgi.com/ariel/freeware/), a working gmake, a
functional f2c (I think? It compiled correctly anyway...) and a
surprisingly uneventful make of octave, which even runs.  And lots
of things work.  Except if you try something like:

octave:25> a\b
11283:octave: rld: Fatal Error: attempted access to unresolvable symbol in /usr/lib/libcruft.so: d_sign

What symbols are unresolvable change with the exact function (e.g.,
it's pow_di when you try "eig" and s_cat for "svd" and "pinv"), but
something is obviously wrong with parts of libcruft.so :-(
Interestingly, though, ffts work fine.  Random numbers work.  "lu"
does not work.  I sort of detect the pattern here, but not the answer.

The only other clue I have is that I had to create symbolic links
from /usr/lib to the .so libraries in /usr/freeware/lib, which
presumably had something to do with a load path variable somewhere.
But I don't see how this accounts for the current misbehavior.  And
all my friends are beginning to think I'm insane at best.

Does anybody have any clues here?

Sorry for the clueless tone of this message, but I see nothing in
the relevant installation or FAQs that give me even a hint, and this
isn't my area of expertise.

jking
[hidden email]


Reply | Threaded
Open this post in threaded view
|

fatal errors running octave 2.09 under Irix6.2 (in libcruft.so?)

John W. Eaton-6
On 20-Aug-1997, Jonathan King <[hidden email]> wrote:

| But this is Irix6.2, so it took me the better part of two days to
| get a working gcc2.7.2.2 and libg++ (binaries from
| http://reality.sgi.com/ariel/freeware/), a working gmake, a
| functional f2c (I think? It compiled correctly anyway...) and a
| surprisingly uneventful make of octave, which even runs.  And lots
| of things work.  Except if you try something like:
|
| octave:25> a\b
| 11283:octave: rld: Fatal Error: attempted access to unresolvable symbol in /usr/lib/libcruft.so: d_sign
|
| What symbols are unresolvable change with the exact function (e.g.,
| it's pow_di when you try "eig" and s_cat for "svd" and "pinv"), but
| something is obviously wrong with parts of libcruft.so :-(
| Interestingly, though, ffts work fine.  Random numbers work.  "lu"
| does not work.  I sort of detect the pattern here, but not the answer.
|
| The only other clue I have is that I had to create symbolic links
| from /usr/lib to the .so libraries in /usr/freeware/lib, which
| presumably had something to do with a load path variable somewhere.
| But I don't see how this accounts for the current misbehavior.  And
| all my friends are beginning to think I'm insane at best.
|
| Does anybody have any clues here?

Some, but I can only guess because you haven't provided all the
information I need.  (Useful information includes whatever would
normally be part of a complete bug report.)

Anyway, my guess is that since the unresolved functions that you
mention are all from the libF77 part of libf2c, something is not right
with your installation of libf2c.  Did you include all the .o files
from libI77 and libF77 when you built libf2c?  What was the output
from running configure on your system?  What was the final link
command when you built Octave?

jwe


Reply | Threaded
Open this post in threaded view
|

Re: fatal errors running octave 2.09 under Irix6.2 (in libcruft.so?)

Jonathan King-3
In reply to this post by Jonathan King-3
"John W. Eaton" <[hidden email]> wrote:

>
>On 20-Aug-1997, Jonathan King <[hidden email]> wrote:
>|
>| [about depressing unresolved symbol errors]
>
>| Does anybody have any clues here?
>
>Some, but I can only guess because you haven't provided all the
>information I need.  (Useful information includes whatever would
>normally be part of a complete bug report.)

Sorry; this was a rush job before they locked up the building.

>Anyway, my guess is that since the unresolved functions that you
>mention are all from the libF77 part of libf2c, something is not right
>with your installation of libf2c.

Looks like that might be a winner.  See below.

>Did you include all the .o files
>from libI77 and libF77 when you built libf2c?

This might be relevant:  The package I grabbed off of netlib claimed
to build the whole libf2c in one fell swoop rather than libI77 and
libF77. But it did seem to build a libf2c.a (not a libf2c.so) and
put it where it was supposed to in /usr/freeware/lib.  However...

>What was the output
>from running configure on your system?

I must really be losing it.  There was reams and reams of
config.log, and a bunch of other config.* files, but the only place I
could really find the "results" of confis was in the text of
octave-bug. Is this correct?  Anyway:

[snipping the top]

# Configuration:  these variables are filled in when running make to
# compile Octave.

config_opts="--prefix=/usr/freeware --enable-shared --enable-dl"
VERSION="2.0.9"
MACHINE="mips-sgi-irix6.2"
F77=""
FFLAGS=""
FPICFLAG=""
FLIBS=""
F2C="f2c"
F2CFLAGS=""
CPPFLAGS=""
INCFLAGS="-I/usr/freeware/include -I/usr/freeware/include/octave-2.0.9"
CC="gcc"
CC_VERSION="2.7.2.2"
CFLAGS="-DHAVE_CONFIG_H  -g -O2 -Wall"
CPICFLAG=""
CXX="c++"
CXX_VERSION="2.7.2.2"
CXXFLAGS="-DHAVE_CONFIG_H  -fno-implicit-templates  -g -O2 -Wall"
CXXPICFLAG=""
LDFLAGS="-g"
LIBFLAGS="-L/usr/freeware/lib"
RLD_FLAG="-L/usr/freeware/lib"
CXXLIBS="-lsocket -lsun -lsocket -lsun -lstdc++ -lm -L/usr/gnu/lib/gcc-lib/mips-sgi-irix5.3/2.7.2.2 -L/usr/gnu/lib -lsocket -lsun -lstdc++ -lm -lgcc -lc -lgcc"
TERMLIBS="-lcurses"
LIBS=""
LEXLIB=""
LIBPLPLOT=""
LIBDLFCN=""

And then reams of symbols.  But I presume it's a very bad sign that
libf2c doesn't show up *anywhere* here; where should it have been?

Assuming that gets fixed, is it okay to have a libf2c.a when most of
the other libraries are libfoo.so and I asked for --enabled-shared?
In any case, I'll rebuild and install libf2c and see if that changes
my configuration and my luck.  

I guess I do find it weird that configure didn't spit out an
obvious message like "Can't build octave without some kind of
usable fortran set-up, so don't even try."

jking

(Configure'd symbol definitions follow, just in case they shed some
light.)

DEFS="-DOCTAVE_SOURCE=1 -DSEPCHAR=':' -DSEPCHAR_STR=\":\" -DUSE_GNU_INFO=1 -DUSE_READLINE=1 -DF77_APPEND_UNDERSCORE=1 -DHAVE_LIBSUN=1 -DHAVE_LIBSOCKET=1 -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DSTDC_HEADERS=1 -DHAVE_DIRENT_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_SYS_WAIT_H=1 -DHAVE_ASSERT_H=1 -DHAVE_CURSES_H=1 -DHAVE_FCNTL_H=1 -DHAVE_FLOAT_H=1 -DHAVE_GRP_H=1 -DHAVE_IEEEFP_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MEMORY_H=1 -DHAVE_NAN_H=1 -DHAVE_PWD_H=1 -DHAVE_SGTTY_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_RESOURCE_H=1 -DHAVE_SYS_SELECT_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_SYS_TIMES_H=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_UTSNAME_H=1 -DHAVE_TERMIO_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_UNISTD_H=1 -DHAVE_VARARGS_H=1 -DHAVE_ATEXIT=1 -DHAVE_BCOPY=1 -DHAVE_BZERO=1 -DHAVE_DUP2=1 -DHAVE_ENDGRENT=1 -DHAVE_ENDPWENT=1 -DHAVE_EXECVP=1 -DHAVE_FCNTL=1 -DHAVE_FORK=1 -DHAVE_GETCWD=1 -DHAVE_GETEGID=1 -DHAVE_GETEUID=1 -DHAVE_GETGID=1 -DH!
AVE_GETGRENT=1 -DHAVE_GETGRGID=1
 -DHAVE_GETGRNAM=1 -DHAVE_GETHOSTNAME=1 -DHAVE_GETPGRP=1 -DHAVE_GETPID=1 -DHAVE_GETPPID=1 -DHAVE_GETPWENT=1 -DHAVE_GETPWNAM=1 -DHAVE_GETPWUID=1 -DHAVE_GETUID=1 -DHAVE_GETWD=1 -DHAVE_LSTAT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MKFIFO=1 -DHAVE_PIPE=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=1 -DHAVE_RINDEX=1 -DHAVE_RMDIR=1 -DHAVE_SETGRENT=1 -DHAVE_SETPWENT=1 -DHAVE_SETVBUF=1 -DHAVE_SIGACTION=1 -DHAVE_SIGPENDING=1 -DHAVE_SIGPROCMASK=1 -DHAVE_SIGSUSPEND=1 -DHAVE_STAT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRDUP=1 -DHAVE_STRERROR=1 -DHAVE_STRNCASECMP=1 -DHAVE_TEMPNAM=1 -DHAVE_UMASK=1 -DHAVE_UNLINK=1 -DHAVE_USLEEP=1 -DHAVE_VFPRINTF=1 -DHAVE_VSPRINTF=1 -DHAVE_WAITPID=1 -DHAVE_LIBDL=1 -DHAVE_DLOPEN=1 -DHAVE_DLSYM=1 -DHAVE_DLERROR=1 -DHAVE_DLCLOSE=1 -DWITH_DL=1 -DWITH_DYNAMIC_LINKING=1 -DHAVE_LIBM=1 -DHAVE_FINITE=1 -DHAVE_ISNAN=1 -DHAVE_ACOSH=1 -DHAVE_ASINH=1 -DHAVE_ATANH=1 -DHAVE_ERF=1 -DHAVE_ERFC=1 -DHAVE_ST_BLKSIZE=1 -DHAVE_ST_BLOCKS=1 -DHAVE_ST_RDEV=1 -DHAVE_TZNAME=1 -DHAVE_GR_PASSWD=1 -DEXCEPTION_!
IN_MATH=1 -DRETSIGTYPE=void -DHA
VE_SYS_SIGLIST=1 -DHAVE_POSIX_SIGNALS=1 -DHAVE_GETRUSAGE=1 -DHAVE_TIMES=1"


Reply | Threaded
Open this post in threaded view
|

Re: fatal errors running octave 2.09 under Irix6.2 (in libcruft.so?)

John W. Eaton-6
On 21-Aug-1997, Jonathan King <[hidden email]> wrote:

| This might be relevant:  The package I grabbed off of netlib claimed
| to build the whole libf2c in one fell swoop rather than libI77 and
| libF77. But it did seem to build a libf2c.a (not a libf2c.so) and
| put it where it was supposed to in /usr/freeware/lib.  However...

It's probably ok that libf2c is not a shared library.

| >What was the output
| >from running configure on your system?
|
| I must really be losing it.  There was reams and reams of
| config.log, and a bunch of other config.* files, but the only place I
| could really find the "results" of confis was in the text of
| octave-bug. Is this correct?

I meant the output that is printed to the screen, for starters.

| And then reams of symbols.  But I presume it's a very bad sign that
| libf2c doesn't show up *anywhere* here; where should it have been?

It should be in FLIBS.  You can either fix your installation so
that configure can find libf2c, then rerun configure, or you can edit
Makeconf and define FLIBS to be -lf2c or /dir/where/libf2c/lives/libf2c.a.

| I guess I do find it weird that configure didn't spit out an
| obvious message like "Can't build octave without some kind of
| usable fortran set-up, so don't even try."

If Octave's configure script fails to find a compatible fortran
compiler or f2c, it prints:

  configure: warning: in order to build octave, you must have a compatible
  configure: warning: Fortran compiler or f2c installed and in your path.
  configure: error: See the file INSTALL for more information.

If it finds f2c but fails to find libf2c, it prints:

  configure: warning: I found f2c but not libf2c.a, or libF77.a and libI77.a

I realize that these messages are somewhat buried in the list of all
the others.  I'll consider making these problems fatal and adding a
--with-f77libs=ARG option to allow overriding the default.

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Re: fatal errors running octave 2.09 under Irix6.2 (in libcruft.so?)

Jonathan King-3
In reply to this post by Jonathan King-3
jwe wrote:
>
>On 21-Aug-1997, Jonathan King <[hidden email]> wrote:
>|
>| This might be relevant:  The package I grabbed off of netlib claimed
>| to build the whole libf2c in one fell swoop rather than libI77 and
>| libF77. But it did seem to build a libf2c.a (not a libf2c.so) and
>| put it where it was supposed to in /usr/freeware/lib.  However...
>
>It's probably ok that libf2c is not a shared library.

But probably not okay that libf2c as built doesn't seem to have any
global symbols in it. :-(

This is the root of the problem, it appears: the config test for
libf2c was checking for f_open (or something), saw nothing, and
decided libf2c didn't really exist. It did exist, but it was
useless.  I can force it to use the useless libraries by editing
Makeconf, but unsurprisingly, that's useless, too.

I'm having similar problems with libF77 and libI77 packages which I
also pulled off of netlib.  I haven't figured out how to tweak the
makefiles supplied with any of these to generate usable libraries
yet, but I expect that will become clear after I get some sleep.
(Probably I should just figure out what octave was doing and do
that, too.)

At the moment, I'm still lost in a battle of whose ar to use (gnu vs
Irix) and/or how to get Irix to create something gcc can use
(apparently also involves 32- vs. 64-bin issues as well; urgh).

Anyway, assuming I discover the magical incantations tomorrow, would
anybody else out there be interested if I made up a binary
distribution of octave for Irix 6.2?

jking