From octave-maintainers-request at bevo dot che dot wisc dot edu Fri Dec 27 22:10:48 2002
Subject: Re: changes to path searching
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov>
Cc: octave-maintainers mailing list <octave-maintainers at bevo dot che dot wisc dot edu>
Date: Fri, 27 Dec 2002 22:10:09 -0600

On 27-Dec-2002, Paul Kienzle <pkienzle at jazz dot ncnr dot nist dot gov> wrote:

| On Fri, Dec 27, 2002 at 02:52:29PM -0600, John W. Eaton wrote:
| > In octave_dynamic_loader::load, we search the currently loaded .oct
| > files for the symbol before actually loading the file, so yes, I think
| > this is still a problem.  I suppose that instead of searching all the
| > currently loaded .oct files, we should only search the one that we are
| > currently loading (if it has already been loaded) otherwise, load it
| > and search.  This requires maintaining a list of filename to dynamic
| > library handles in the dynamic loader module, but that is easy enough
| > to do.  Would that solve the problem?
| 
| That will only solve the problem if you can recognize that two files are
| the same.  That should be easy enough, no?  If it is a symbolic link,
| dereference it until you get to the base file, then check if that file is
| already loaded, otherwise load it.  As a bonus, you don't have to search
| through all loaded files.
| 
| This may make life slightly more difficult for some if they are relying on
| the fact that for example myconstructor() will automatically load all
| associated functions for their type and they don't need symlinks to
| myconstructor.oct.
| 
| This will also make life difficult for a native windows port in that
| windows has dodgy support for symbolic links.  I suppose I can write some
| special code for windows so that xxx.lnk is a text file which contains the
| relative path to the oct which exports the function.  I'll worry about that
| when I have more time to work on the native port.

OK, I'm convinced that what we are doing now is not the right thing,
and my simple idea of a filename to shared library handle map also has
some problems.

So what should happen when we need to load functions from .oct files?
If running a function from a single file (say "foo" from "foo.oct")
actually installs multiple functions, then I think we can come up with
a simple solution that will work OK, at least until someone clears
some functions, updates a .oct file, or installs a new .oct file in the
path ahead of the old one (forcing a reload).  Then I'm not sure what
should happen.  Currently reloading forces all functions that have
been loaded from a single file to be cleared.  But that will only work
if Octave was the one loading the functions into the symbol table --
if you do it with some code in your own loadable file, Octave won't
know about those functions, so it won't clear them.  Then I think
closing the shared library and reloading could cause some trouble.

jwe