Patch adding *.oct to rebaseall for cygwin
James R. Phillips
Mon Jul 11 14:40:00 GMT 2005
--- Jason Tishler wrote:
> Please give me more than ~36 hours to respond to a post. FWIW, I was on
> vacation when you posted to cygwin-apps@.
Sorry to bother you. I'm going on vacation myself shortly. I didn't repost
because of impatience, it was because I was told I was posting patches in the
wrong list. I did further research and found no information telling me
authoritatively where to post patches. However, since I subscribed to the
cygwin mailing list digest, I see many patches are posted in there, without
> rebaseall currently handles .dll files and the next version will handle
> .so files too. I would prefer not to change rebaseall to handle
> non-standard shared library extensions. Instead, can you change Cygwin
> octave to use one of the standard extensions for its shared libraries?
Not sure. octave does build and use several normal dll's, for parsing etc.
The .oct files are binary implementations of octave functions, similar to
matlab .mex files. Quite a few of these are compiled when octave is built, and
if octave-headers is installed, the user can write new ones in c++ or fortran.
I have seen (but not on the current cygwin version) the dreaded "reload failed"
error appear on my console, referencing a .oct file, and so I assumed it must
be structurally the same as a dll. And I found experimentally that rebase will
The issue is that octave documentation and long-established convention both
lead to ending these files in ".oct", regardless of platform. So it seems
unlikely that upstream would want to change that. And maintainer for a single
platform I am not in a good position to support this concept if upstream
doesn't want to.
Since this problem has not been demonstrated to occur with the current package,
I might just include a current patch against rebaseall with instructions for
use in /usr/share/doc/octave-<version> directory, as insurance against the day
it does recur.
More information about the Cygwin-apps