help-octave
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: compile problem on redhat linux


From: Huaiyu Zhu
Subject: Re: compile problem on redhat linux
Date: Wed, 16 Dec 1998 16:47:25 -0700 (MST)

Hope the following might help. I upgraded from RH4.2 to RH5.1, yesterday
(a step behind you, but who needs upgrade if things have been working
perfectly?).  My octave 2.0.13 also broke on C++. Turned out to be
a package like egcs++ or some similar name. I just searched the CD for 
all names with ++ and rpm -Uhv --force. Afterwards octave compiles without
a hitch.

-- 
Huaiyu Zhu                      Tel: 1 505 984 8800 ext 305       
Santa Fe Institute              Fax: 1 505 982 0565
1399 Hyde Park Road             mailto:address@hidden          
Santa Fe, NM 87501              http://www.santafe.edu/~zhuh/  
USA                             ftp://ftp.santafe.edu/pub/zhuh/  

On Wed, 16 Dec 1998, Stefano Ghirlanda wrote:

> > 
> > | I recently upgraded to redhat 5.2, from 5.1. My octave 2.0.12
> > | understandably crashed at startup, due to change in the libraries.
> > | So I try to recompile it. I tried both with the sources I had and with a
> > | source rpm (the binary rpm in the redhat contrib directory also has
> > | incompatible libstdc++). I get the same error:
> 
> <snip>
> 
> > The current test release doesn't use the macro NAN.  Can you please
> > try using that instead, and let me know if it works?  You can get the
> > current test release from ftp.che.wisc.edu in the directory
> > /pub/octave.
> 
> With this one things go better, but the very final linking step to produce
> octave fails. The linker cannot find what seem to me very  straightforward
> functions:
> 
> make[2]: Entering directory `/usr/local/src/octave-2.0.13.95/src'
> c++  -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../glob
> -I../glob -D
> HAVE_CONFIG_H -mieee-fp -fno-rtti -fno-exceptions -fno-implicit-templates
> -g -O2
>  -Wall -rdynamic \
> -L.. -u MAIN__  -fPIC -g -o octave \
> octave.o builtins.o  balance.o  besselj.o  betainc.o  chol.o  colloc.o
> dassl.o  det.o  eig.o  expm.o  fft.o  fft2.o  filter.o  find.o  fsolve.o
> gammainc.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 \
> -L../liboctave -L../libcruft -L../src -Xlinker -rpath -Xlinker
> /usr/local/lib/oc
> tave-2.0.13.95 \
> ../src/liboctinterp.a ../liboctave/liboctave.a  ../libcruft/libcruft.a
> ../readl
> ine/libreadline.a ../kpathsea/libkpathsea.a ../glob/libglob.a  \
> -lf2c  -lncurses -ldl -lm 
> ../src/liboctinterp.a(load-save.o): In function
> `get_lines_and_columns(istream &
> , basic_string<char, string_char_traits<char>, __default_alloc_template<1,
> 0> > const &, int &, int &)':
> /usr/local/src/octave-2.0.13.95/src/load-save.cc:1015: undefined reference
> to `i
> stream::seekg(long long, ios::seek_dir)'
> 
> ... more undefined refs to stream stuff follow ...
> 
> So I suspect that something is wrong with my current c++ setup.
> Moreover, I found out that it's not a wrong-lib-version thing that makes
> the "official" rpm fail. I got the right libraries with symlinks and so
> on. I get the following bt from gdb:
> 
> (gdb) run
> Starting program: /usr/bin/octave 
> Octave, version 2.0.13 (i386-redhat-linux-gnu).
> Copyright (C) 1996, 1997, 1998 John W. Eaton.
> This is free software with ABSOLUTELY NO WARRANTY.
> For details, type `warranty'.
> 
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0 in ?? ()
> (gdb) bt
> #0  0x0 in ?? ()
> #1  0x4045e07f in __overflow (f=0x809c998, ch=0) at genops.c:181
> #2  0x4045bcc1 in _IO_putc (c=0, fp=0x809c998) at putc.c:33
> #3  0x400b1cca in octave_pager_buf::sync ()
> #4  0x403ee6b5 in ostream::flush ()
> #5  0x400b22b7 in flush_octave_stdout ()
> #6  0x40084709 in octave_gets ()
> #7  0x400849e5 in get_user_input ()
> #8  0x40084a85 in octave_read ()
> #9  0x4008c35e in yy_get_next_buffer ()
> #10 0x4008c075 in yylex ()
> #11 0x400b446b in yyparse ()
> #12 0x400f42e6 in main_loop ()
> #13 0x805256c in main ()
> 
> I hope this is clearer to you than to me.
> I'll check my c++ setup, it would not be the first time that things went
> wrong with a redhat upgrade (to me, at least).
> Thanks for all support,
> Stefano
> 
>  Stefano Ghirlanda, Zoologiska Institutionen, Stockholms Universitet
>     Office: D554, Arrheniusv. 14, S-106 91 Stockholm, Sweden
> Phone: +46 8 164055, Fax: +46 8 167715, Email: address@hidden
>    Support Free Science, look at: http://rerumnatura.zool.su.se
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]