Re: I don't have functions like inv, pinv, det - build problem?

[John W. Eaton]

On 27-Feb-2007, "Hakan Yüksel" wrote:

| Hello,
| 
| 
| > After specifying --prefix=/usr, why were you expecting to find
| > the .oct files in /usr/lib/octave/... instead of
| > /usr/libexec/octave/...?
| 
| 
| I have a source based linux distro. After having the mentioned problems with 
the self compiled source tarball of octave-2.1.73, I have installed binary 
packages of octave-2.1.73 on two other platforms. I have installed the binary 
packages on Ubuntu 6.10 and on cygwin. On both systems I did not have the 
problems. When I typed there "help inv" for example, I got the following output:
| 
| octave:1> help inv
| inv is the dynamically-linked function from the file
| /usr/lib/octave/2.1.73/oct/i686-pc-cygwin/inv.oct
| 
| That's the reason why I was expecting to find the .oct files in 
/usr/lib/octave/.

I'm not sure I understand precisely what you did.  Did you look at the
output of help inv on one system and then assume that it would be the
same for all systems?

| I have had the idea of specifying --libexecdir after typing "./configure 
--help" on my source distro. And that has solved my problem.
| 
| 
| > What I'm trying to tell you is that if you use --prefix=/usr only (no
| > --libexecdir option) then it should work, but you won't have the
| > /usr/lib/octave/... directory tree but you should have a
| > /usr/libexec/octave/... direoctry tree that contains the .oct files,
| > and the /usr/libexec/octave/... directory tree should appear in your
| > DEFAULT_LOADPATH directory, so Octave should be able to find the
| > files.  You should not have to specify both --usr and --libexecdir
| > configure options for Octave to work properly.
| 
| 
| I understand what you mean, but after my originally build without using 
libexecdir but only "--prefix=/usr" I definitely did not have "/usr/libexec" or 
"/usr/lib/octave" or any other folder with the *.oct-files. I have searched my 
whole file system for the *.oct-files. There is a significant difference 
between "should be" and "is".
| 
| So this seems to be a bug in the configure script.

I don't think so.  When I build Octave 2.1.73 with

  configure --prefix=/tmp/foobar --enable-shared --disable-static

I see:

  octave:1> DEFAULT_LOADPATH
  DEFAULT_LOADPATH = 
.:/tmp/foobar/libexec/octave/2.1.73/site/oct/x86_64-unknown-linux-gnu//:/tmp/foobar/libexec/octave/site/oct/api-v13/x86_64-unknown-linux-gnu//:/tmp/foobar/libexec/octave/site/oct/x86_64-unknown-linux-gnu//:/tmp/foobar/share/octave/2.1.73/site/m//:/tmp/foobar/share/octave/site/api-v13/m//:/tmp/foobar/share/octave/site/m//:/tmp/foobar/libexec/octave/2.1.73/oct/x86_64-unknown-linux-gnu//:/tmp/foobar/share/octave/2.1.73/m//
  octave:2> LOADPATH
  LOADPATH = :
  octave:3> help inv
  inv is the dynamically-linked function from the file
  /tmp/foobar/libexec/octave/2.1.73/oct/x86_64-unknown-linux-gnu/inv.oct
  [...]

So I think this works correctly.

The only way I can think of that you would get a different result is
if somehow your binary was linked with a copy of liboctave that was
built with a different --prefix/--libexec combination (Debian, for
example, forces --libexec=/usr/lib because by default Debian doesn't
have /usr/libexec).  Did you have another copy of the Octave 2.1.73
libraries installed on your system when you built your own copy from
source?

jwe