help-octave
[Top][All Lists]
Advanced

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

More on API for Octave


From: John W. Eaton
Subject: More on API for Octave
Date: Fri, 24 Apr 1998 03:18:22 -0500 (CDT)

On 23-Apr-1998, address@hidden <address@hidden> wrote:

| I read the conversation between Haisam K. Ido <address@hidden>
| and John W. Eaton <address@hidden> about an API for Octave,
| that contained this gem:
| 
|   If you are using C++, you can call any of the functions in the
|   liboctave library fairly easily, but currently it works best
|   if you are creating .oct files, not standalone applications. 
| 
| I find this excruciatingly true.

Sorry.  :-(

| mkoctfile works like a charm.
| Anybody want to give hints how to link up a _standalone_ c++ program
| that uses the (nice, well debugged) octave matrix math classes?
| 
| At the moment, I am using octave-2.0.5 on Red Hat Linux 4.2,

Octave 2.0.5 is ancient.  It has lots of bugs compared to the current
release, 2.0.11 (with 2.0.12 to be released RSN).  No one should be
running 2.0.5 now.

| but I can change to some other version if it would help.
| Even after I get diarrhea of the -l options to gcc (-lf2c -loctave
| -lcruft -lOctaveReadline -lncurses ...) I get stuck with
| unresolved symbols -- symbols that seem to already be in -l'd
| libraries.

You should be able to use the same list of libraries that Octave
itself uses.  If you use them in the same order, I would expect all
the references to be resolved.  As far as I know, the Octave libraries
don't have any mutual dependencies.

Recently, I've moved some code into liboctave that depends on the
readline, kpathsea, and glob libraries, so they are also required by
any program that you try to write using liboctave/libcruft, even if
you don't use the path searching or command editing code.  I'd like to
fix this for a future release, but it's not a high priority item for
me (the only code I work on that uses liboctave is Octave, so this
limitation doesn't bother me much).  Would someone like to sort out
exactly what modules need to be removed from liboctave so that it
doesn't require the kpathsea, readline, and glob libraries?  Then
those functions could be placed in a separate library
(liboctave-util?) and you wouldn't have to link to that unless you
actually needed the code.

Thanks,

jwe




reply via email to

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