Building octave 2.0.8 and later on Linux

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

Building octave 2.0.8 and later on Linux

Dirk Laurie
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?

Problem 2: ld: cannot open -lieee: No such file or directory
Not solved; can't even identify a package offering libieee.a
or similar.

Dirk


Reply | Threaded
Open this post in threaded view
|

Building octave 2.0.8 and later on Linux

John W. Eaton-6
On 11-Jul-1997, Dirk Laurie <[hidden email]> 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.

In any case, can someone say why termcap.h isn't installed in
/usr/include on this system?

| 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.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: Building octave 2.0.8 and later on Linux

Dirk Eddelbuettel-2

  John> In any case, can someone say why termcap.h isn't installed in
  John> /usr/include on this system?

Don't know RedHat, but on Debian, you need to install the ncurses-dev package
to be able to compile (as opposed to just run) ncurses/termcap.

--
[hidden email]  [hidden email]  http://rosebud.sps.queensu.ca/~edd
PGP KeyID 1024/6D7F08DD     Boycott Internet Spam: http://spam.abuse.net/spam/



Reply | Threaded
Open this post in threaded view
|

Re: Building octave 2.0.8 and later on Linux

Dirk Laurie
In reply to this post by John W. Eaton-6
John W. Eaton wrote:

>
> On 11-Jul-1997, Dirk Laurie <[hidden email]> 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