--- Jason Tishler wrote: > Please give me more than ~36 hours to respond to a post. FWIW, I was on > vacation when you posted to [EMAIL PROTECTED]
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 objections. > > 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 handle them. 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.
