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

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.

Paul Kienzle
pkienzle at users dot sf dot net