[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Relocatable octave
From: |
Thomas Treichl |
Subject: |
Re: Relocatable octave |
Date: |
Fri, 01 Jun 2007 18:33:22 +0200 |
User-agent: |
Thunderbird 1.5.0.12 (Macintosh/20070509) |
Paul Kienzle schrieb:
On May 31, 2007, at 2:02 PM, John W. Eaton wrote:
Yes, if setting OCTAVE_HOME before starting Octave is not sufficient
to allow it to be installed in any directory and still work, then
please report the details of the bug. If you move the entire Octave
installation and preserve the relative directory structure, then I
don't think you should have to set individual variables like EXEC_PATH.
Okay, that helps a lot. It means we won't have to shimmer names for
things such as the script file paths.
This will of course not work for redirecting the shared libraries.
Processing of OCTAVE_HOME happens in liboctinterp.{dll,dyld,so}, so it
obviously can't happen if {PATH,{DY,}LD_LIBRARY_PATH} is not set
properly beforehand. You could make the octave 'command' a shell script
which adjusts the appropriate variables based on OCTAVE_HOME prior to
running octave main, but is that worth the trouble?
Wow, ...
In principal this looks very very good now. Nearly every octave_config_info
entry is correctly be replaced and commands like 'doc' etc. do work very well. Eg.
...
bindir = /Users/MyHome/tmp/octave.app/Contents/Resources/bin
...
includedir = /Users/MyHome/tmp/octave.app/Contents/Resources/include
infodir = /Users/MyHome/tmp/octave.app/Contents/Resources/info
infofile = /Users/MyHome/tmp/octave.app/Contents/Resources/info/octave.info
...
There are some entries left - I don't know if they should also be replaced (if
you please could have a look at them):
MKOCTFILE_DL_LDFLAGS = -bundle -bundle_loader \
/tmp/octave-2.9.12/bin/octave-2.9.12
SONAME_FLAGS = \
-install_name /tmp/octave-2.9.12/lib/octave-2.9.12/oct-conf.h
config_opts = 'CC=gcc' 'CPP=cpp' 'CXX=g++' 'F77=gfortran' \
'CFLAGS=-I/opt/local/include' 'CPPFLAGS=-I/opt/local/include' \
'LDFLAGS=-L/opt/local/lib' '--enable-shared' '--disable-static' \
'--prefix=/tmp/octave-2.9.12'
A test gave me
octave:14> mkoctfile oregonator.cc
/usr/bin/ld: can't open: /tmp/octave-2.9.12/bin/octave-2.9.12 \
(No such file or directory, errno = 2)
collect2: ld returned 1 exit status
warning: mkoctfile exited with failure status
So I needed to set up (at least)
export DL_LDFLAGS "-bundle -bundle_loader \
/Users/MyHome/octave.app/Contents/Resources/bin/octave-2.9.12"
but I do think that this isn't the right path I'm taking even if it does work
with this environment variable (LDFLAGS -> bin)?!
It will be interesting to see how many problems are caused by spaces in
OCTAVE_HOME. There will be at least one: mkoctfile.m will fail with a
space in bindir because it doesn't quote the command or the arguments
before calling system(). Michael, can you test whether you can still do
package builds if bindir is not part of the mkoctfile command on your
windows build, and submit a patch if that is the case?
- Paul
Yes ;) the biggest problem is that I cannot even check this because our Mac
octave.app doesn't feed through a path information to our startup script with a
space in between but splits this into more than one string. So
open octave.app
where the octave.app is somewhere in /Users/MyHome/tmp/my\ test/octave.app
breaks with an error before octave is called.
Thomas