Dropping William as well, I suspect he didn't really want to know
about this stuff.
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()] .
That's been working for a couple of days, but I didn't update your
tarball. I just made a new 0.5 tarball that includes the latest MinGW
functionality. Maybe you should update so you see what's left to do:
http://www.math.mcgill.ca/loisel/octave-gui/octave-gui-0.5.tar.gz
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?