Douglas Brebner <douglas+list at fang.demon.co.uk> wrote:
> On Fri, 18 Aug 2000, Ian Piumarta wrote:
> > 
> > Well, this kind of ignores an important source of headaches.  Squeak
> > is trying to use .so files in cruel and unusual ways that many Unix
> > designers never dreamed of (even in their worst nightmares).  On some
> > platforms (including at least one of the supported ones, I might add)
> > it is *impossible* for the loader to figure out the dynamic
> > dependencies for the VM unless the plugins are (i) installed in a
> > standard place that ld.so knows about; (ii) prefixed with "lib", and
> > (iii) suffixed by ".so.<maj>.<min>".  This makes the build kind of
> > tricky, since a partial install is absolutely required at "half-time".
> 
> On ELF platforms, can't you use -Wl,-R/path/to/plugins to embed the library
> search path into the executable itself?
> 

At least on Linux, what Squeak does fits very well with the intentions
of the mechanisms--in fact, many other packages use the same mechanism. 
Perhaps the situation is different on other platforms, of course.

Regarding the location of .so files, most platforms will let you set an
environment variable to add to the lookup path.  I suggest we do this
instead of building a link path into the executable on platforms that
let you -- the environment variable will disappear once the build
process is finished, but the built-in path will stay in the executable
even after its been installed.

On Linux, the variable to use is "LD_LIBRARY_PATH", and usage can look
like this:

	LD_LIBRARY_PATH=./plugins   ./squeak

or, better, like this:

	LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./plugins   ./squeak




By the way, we should pay attention to what it takes to build a plugin. 
In the long run, probably more people will want to build plugins than
will want to rebuild the whole VM.


-Lex