From bug-octave-request at bevo dot che dot wisc dot edu  Tue Nov 18 01:28:45 1997
Subject: Fix for loading oct-files
From: "John W. Eaton" <jwe at bevo dot che dot wisc dot edu>
To: Michael dot Hanke at wias-berlin dot de
Cc: bug-octave at bevo dot che dot wisc dot edu
Date: Tue, 18 Nov 1997 01:29:26 -0600

On 15-Oct-1997, Michael Hanke <Michael dot Hanke at wias-berlin dot de> wrote:

| roughly one month ago I was reporting about a bug which is more
| related to the implementation of the loader library than to
| octave.

Sorry I wasn't able to respond until now.

| In short: If I write a .oct file containing two function definitions
| which share a common global object and make links under both names to
| the same .oct file, some versions of the dynamic loader (I found it in
| IRIX 6.2 and Linux) load two images with the same symbols. This means
| that the "shared" objects are no longer shared!

| So I introduced some new code into  dynamic-ld.cc for
| some bookkeeping in order to avoid this situation. The new text is
| included below.

Can you send context diffs instead?  My sources have also been
changing, so I can't simply replace my copy of this file with
yours.  It's also hard to tell exactly what you changed since I'm not
sure what version you started with.  It would be much easier for me if
I had diffs.

However, I can see that you have modified the code to keep a list of
the open shared libraries (in the form of the pointers returned by
dlopen or shl_load), and then you check that list before trying to
reload a library.  This is ok, but probably won't work correctly with
the changes I made recently that allow .oct files to be cleared.

To do that, I modified the dynamic linking functions so that the
pointers pointers returned from dlopen (shl_load) are cached along
with the other information about the function.  Then, when a .oct
file is cleared, dlclose (shl_unload) is called for the pointer.

If more than one .oct file has been loaded from the same file, Octave
will have to clear more than one function from its symbol table before
it can call dlclose.  Doing that should not be too hard -- we can just
maintain a list of function names that correspond to the same shared
library `handle', and then clear the entire list of functions if any
one in the list is unloaded.  The only question is whether this is
reasonable behavior.

Comments?

Thanks,

jwe