------- Start of forwarded message -------
>
>
> Resent-Date: Wed, 28 Feb 1996 23:08:23 -0500 (EST)
> From: Alex Williams <thantos_at_jerry.alf.dec.com>
> Date: Wed, 28 Feb 1996 22:44:06 -0500 (EST)
> X-Mailer: ELM [version 2.4 PL24]
> Mime-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Resent-From: stk_at_kaolin.unice.fr
> X-Mailing-List: <stk_at_kaolin.unice.fr> archive/latest/1065
> X-Loop: stk_at_kaolin.unice.fr
> Precedence: list
> Resent-Sender: stk-request_at_kaolin.unice.fr
> Content-Type: text/plain; charset=US-ASCII
> Content-Length: 1217
>
>
> Greetings all.
> I'm having a rather interesting issue regarding getting STk 4.0b2
> running under dUNIX 3.2c and 4.0. Under both systems, I find that
> running "make" on the files as they're extracted from the tar file results
> in a runnable binary (using the test-stk script) which puts up a nice
> STk window which can be addressed using the interpreter running in thr
> /original/ window, just as things should be.
> HOWEVER, the moment after typing "make install," which recompiles
> sections of the code and supposedly installs them, I have problems. Running
> using the test-stk script method, even re-edited to take into account moved
> binaries, et al. is no longer effective; it complains of being "in a strange
> place," and suggests setting some env vars, which are set as a result of being
> in the script, itself. Running the now installed binary results in the
> STk interpreter being started, but no Tk window opening, nor are the
> Tk commands apparently active, including addressing *root*. Nota bene: this
> is the same code that was running perfectly /before/ being "installed."
> Even the demos ran (with "make demos") under OSF/1 before the install, but
> not after.
> Ideas, feedback, thoughts?
>
> Alexander
I can answer this, since I just blundered about with it myself.
In response to some prompting from this list, Erick made a major
change in release STk3.0b2. Previously, he had a shell script called
stk (snow) that set environment variables and then invoked stk-bin
(snow-bin). In this release, there is no shell script between you and
the binary. However, the library location is *not* hard-coded into
the executable.
STk now examines argv[0], retrieves the fully-resolved path of the
executable, and looks for the library files relative to that path.
That is, if the executable is found in:
/usr/local/lib/stk/3.0b2/Linux-1.X-ix86
then STk looks in:
/usr/local/lib/stk/3.0b2/STk
for .stk and .stklos files, and so forth. All binary libraries are
stored in a directory keyed by the operating system, OS version, and
processor architecture (hence Linux-1.X-ix86).
As long as your path points to this machine-dependent directory, and
all the library files are in the correct place relative to that
directory, STk will be happy.
I suspect, in your case, that your installed these files correctly,
but that your current working directory was still the STk build
directory. If ``.'' is in your path, an executable ``stk'' is in
``.'', and ``.'' is not OS-OSVERSION-PROCESSOR, you are out of luck.
If not, then something similar is going wrong.
You can set STK_LIBRARY=/usr/local/lib/stk/3.0b2 if you can't get the
configuration.
I think this is a clever solution, except for one thing. I rarely use
STk. Rather, I use STk embedded in my own application, which is
definitely not installed in a public place. STk resolves may
application name, doesn't find the library, and complains. So, I have
a shell script called nvision, and a binary called nvision-bin...and
I'm back to where I was. I have the shell script set the STK_LIBRARY
variable so that visitors don't have to have their environment point
off to some mysterious place to get things to work. I use nvision-bin
directly, expecially since I am commonly running gdb on it...
So, Erick, a proposal.
What if we combine to two solutions. STk should *first* resolve the
pathname, look for a library, and if it finds it, great, go ahead and
use it. If not, check the directory specified at:
./configure --prefix=/my/personal/installation
and use that.
If I have my own library near my own executable, it finds it.
If I have changed the installation directory of the primary stk/snow,
it finds it.
If I have my own executable with no local copy of the library, it will
find the standard one.
In other words, the hard-coded path can serve as a backup to the
dynamically resolved path.
Respectfully submitted,
Cliff
--
Clifford Beshers Computer Graphics and User Interface Lab
beshers_at_cs.columbia.edu Department of Computer Science
http://www.cs.columbia.edu/~beshers 500 W 120th St, Room 450
Office: 212-939-7087 Lab: -7101 Columbia University, New York, NY 10027
Received on Thu Feb 29 1996 - 17:11:24 CET