Why will static linking help you? Why only to liboctave? liboctave will
only give you the libocatve_error_handler and
liboctave_warning_handler. For the Ferror function you'll also need to
link against liboctinterp.
Ok, I may need to link against all that statically, but you would know better.
What about the octave_stdout [ie octave_pager_stream::stream()] .
For this one, open a shell (I use my shell-x64.bat from the previous tarball, this one doesn't have it) and do ./configure && make (you don't need to aclocal && autoconf && automake, it's a make dist.)
Doesn't it help here? As for cerr, unfortunately in error.cc the verror
function is called with std::cerr as the output stream, so the Ferror
function calls go straight to std::cerr. As for the
So either I'd have to link statically against that library, or have a get_cerr() to get that library's cerr, or the library could be modified to write to octave_stdout or something like that.
liboctave_error_handler and liboctave_warning_handler functions defined
in
lo-error.c, these fprintf directly to stderr as well. So for the
I noticed those are function pointers. Would it be reasonable to just reimplement those in my Octave GUI and make the pointers point there? When are these pointers initialized? Are there any other cases where Octave writes straight to cerr, cout, stderr or stdout, instead of using octave_stdout?