help-octave
[Top][All Lists]
Advanced

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

Re: Building octave 2.0.8 and later on Linux


From: Dirk Laurie
Subject: Re: Building octave 2.0.8 and later on Linux
Date: Sat, 12 Jul 1997 13:18:25 +0200 (SAT)

John W. Eaton wrote:
> 
> On 11-Jul-1997, Dirk Laurie <address@hidden> wrote:
> 
> | I downloaded octave 2.0.8 with the idea of building it first,
> | applying the 2.0.9 patch, and re-making.  I'm running Red Hat
> | 4.1 Linux.
> | 
> | Problem 1: termcap.h not found
> | Solved: ln -s /usr/include/ncurses/termcap.h /usr/include/ 
> | Query: since octave seems to use kpathsea, why isn't termcap.h
> | found in the subdirectory?
> 
> I don't quite understand the question.  I assume gcc can't find
> termcap.h when you are trying to compile some file.  I don't see what
> that has to do with kpathsea.
> 
I was under the impression that kpathsea allows one to search for files
in all subdirectories of some root directory, but I suppose that is true
only for octave itself, not gcc.

> In any case, can someone say why termcap.h isn't installed in
> /usr/include on this system?
> 
I'm using ncurses-devel-1.9.9e-4.i386.rpm which is the one shipped with
Red Hat 4.2, and it puts the files into directories as follows:
/usr/include/curses.h
/usr/include/eti.h
/usr/include/form.h
/usr/include/menu.h
/usr/include/ncurses.h
/usr/include/ncurses/curses.h
/usr/include/ncurses/eti.h
/usr/include/ncurses/form.h
/usr/include/ncurses/menu.h
/usr/include/ncurses/panel.h
/usr/include/ncurses/term.h
/usr/include/ncurses/termcap.h
/usr/include/ncurses/unctrl.h
/usr/include/panel.h
/usr/include/term.h
/usr/include/unctrl.h
I don't know the rationale behind this.

> | Problem 2: ld: cannot open -lieee: No such file or directory
> | Not solved; can't even identify a package offering libieee.a
> | or similar.
> 
> After patching to get to 2.0.9, did you recreate the configure scripts
> using autoconf and autoheader (sorry that this is not automated yet)?
> If so, configure should have avoided adding -mieee-fp to the compiler
> flags.  If configure still doesn't do the right thing, the
> README.Linux file has a couple of other alternatives.
> 
Well, I've overkilled now by (a) running autoconf and autoheader
(b) adding an empty src/libieee.a (c) editing specs
(d) rerunning ./configure
The 'make' is now churning in the background and I still see -mieee-fp
among the compiler options, but hopefully overkill item (b) will
fix that. 

Dirk



reply via email to

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