From bug-octave-request at bevo dot che dot wisc dot edu  Thu Sep 11 13:06:48 1997
Subject: Re: Octave vs dlopen BUG: reloading changed .oct crashes!
From: Dennis Decoste <decoste at bananajr dot jpl dot nasa dot gov>
To: decoste at bananajr dot jpl dot nasa dot gov, jwe@bevo.che.wisc.edu
Cc: bug-octave at bevo dot che dot wisc dot edu, edd@rosebud.sps.queensu.ca
Date: Thu, 11 Sep 1997 11:05:59 -0700 (PDT)

> |   Unfortunately, I've quickly discovered that if I've already run a
> |   OCT-based function (e.g. "hello" via examples/hello.oct), then
> |   recompiling any CHANGES to the source (e.g. "mkoctfile hello.cc")
> |   and trying to then rerun the function in the same Octave session
> |   causes Octave to consistently crash.
> 
> I don't know what the dynamic linker is doing on your system that
> would cause Octave to crash, but even if it didn't crash, Octave would
> probably not be doing what you want because there is currently no code
> for unloading .oct files once they are loaded.  So if the timestamp

Ok, I will probably look into this myself then in the near future
and hopefully post a patch soon ... hopefully it's a matter
of just calling dlclose() properly whenever one reopens the
same oct file.  In any case, it should definitely be doable -- MATLAB5,
for example, works just fine with MEX redefinitions, so the
dlopen/dlclose mechanism on Solaris must support such redefs ok.

> on the .oct file changes after it has been loaded, Octave doesn't try
> to reload it.  This might not be too hard to fix, but I haven't had
> time to do it yet.

If the code doesn't explicitly look at the timestamp to
ensure reloading changed *.oct files, then I wonder why it ONLY 
crashes once I recompile the oct file so it actually changes in 
size?!  It sure SEEMS to act like it's trying to use the 
newly changed oct file.

Anyway, again, I'll look into all this and hopefully report back
with success soon ...

-- Dennis