Re: MINGW build

[Mumit Khan]

On Sun, 22 Sep 2002, Paul Kienzle wrote:

> Hi,
>
> I'm disappointed in the performance of octave under CYGWIN, and particularly
> with the socket hack I'm using for communication, so I've been trying to
> build under MINGW to see if performance is any better.

Paul, Thanks for this effort. We had talked about this in the past, but
never bothered going beyond mere words. If the missing POSIX functionality
becomes too much of an issue, we can probably add back some of that by
hand-crafted replacement code.

> liboctave/lo-specfun.cc:
>
>    M_PI is not defined
>
> => move def of M_PI from lo-mappers.cc where it is not needed

M_PI is non-ISO, so it should be #ifdef'd properly. Better yet, auto
configured.

> liboctave/{LP,LPsolve}.h
>
>    LP conflicts with a definition in winnt.h

This is the single biggest problem with MS Windows headers -- namespace
polluted beyond help.

> liboctave/file-ops.cc:
>
>    ::mkdir doesn't accept a mode argument
>
> => proper fix is to check in ./configure if mkdir accepts a mode argument
> I hacked around it rather than fix ./configure.

I added a test to GCC's configure for this way back, which should be
sufficient for Octave. It's trivial -- I'll work up a patch.

>
> liboctave/lo-mappers.cc:
>
>    compiler crashes when trying to call the octave error handler
>
> => compiling without -O2 avoids the problem.  I don't know the correct fix.

I may have an idea why, but I need to look at it in detail first.

> liboctave/lo-mappers.cc:
>
>    isnan is not picked up in lo-mappers even though configure found it.

You need to compile lo-mappers.cc with  -save-temps and see what's going
on. Also, note that isnan is non-ISO C++, which means that one should not
use a "C" test in configure to detect the presense. Using Sun-Forte
compiler for example, I needed to revert to using "math.h" instead of
"cmath" to work around this issue.

> liboctave/lo-specfun.cc:
>
>    dacosh, dasinh, datanh, derf, derfc undeclared
>
> => use the declared x... functions --- why do we need the x... versions?
>
> liboctave/cmd-edit.cc:
>
>    ::geteuid undeclared
>
> => test for geteuid in configure and use the following:
>
>   #if defined(HAVE_GETEUID)
>     temp = (::geteuid () == 0 ? "#" : "$" )
>   #else
>     temp = "$";
>   #endif
>
> src/debug.cc:
>
>   index undecared
>
> => use strchr like the rest of octave
>
> src/sighandlers.cc:
>
>
>   kill undeclared
>   SIGCHLD etc. undefined
>   SIGPIPE undefined
>
> => I don't know how to do windows signal handling.  I was going to work on
> this after I got the basics working.  I hacked out the kill code.  The
> two functions sigchld_handler and sigpipe_handler should be wrapped #if's
>   #ifdef SIGCHLD
>   sigchld_handler (...) { ... }
>   #endif /* SIGCHLD */
>
>   #ifdef SIGPIPE
>   sigpipe_handler (...) { ... }
>   #endif /* SIGPIPE */

Signal handling is fundamentally different in Windows and Unix, and it's
really not worth trying to emulate these unless you're in the mood to
write some serious code.

>
> src/sysdep.cc:
>
>   termio stuf undefined
>
> => I will need to write a windows replacement for kbhit.  MinGW defines
> termio.h, but it is empty.  I hacked around this with an #ifdef WIN32
> but that is not the best solution.  Again, not needed for the first cut.
>
> src/sysdep.cc:
>
>   sleep undeclared

sleep is known as _sleep, and it takes milliseconds, not seconds (off by 3
orders of magnitude bugs). I would prefer to see Sleep instead. Once your
code is in CVS, I can probably help a bit.

>
> => surprisingly usleep didn't cause problems.  I don't know what the
> consequences of using usleep rather than sleep are here.  I just commented
> it out, so pause and sleep will be broken.
>
> src/toplev.cc
>
>    fork undeclared

No such thing under Windows. There are "emulations" without using full
blown packages like Cygwin, but that's an overkill.

>
> => comment it out --- system() will not work initial.
>
> src/{parse.h,lex.l,y.tab.h}
>
>    TEXT redefined in winnt.h
>
> => use token STRING rather than token TEXT
>
> src/pt-bp.cc
>
>    lst1, lst2 defined in dlgs.h
>
> => use lstA and lstB instead --- this is easier than figuring out exactly
> why dlgs.h is being included.
>
> kpathsea/config.h
>
>    The following leads to all sorts of conflicts:
>
>    #ifdef WIN32
>    #define __STDC__ 1
>    #include <kpathsea/win32lib.h>
>    #endif
>
> => instead  use something like
>
>    #ifdef MINGW
>    #include <windws.h>
>    #include <fcntl.h>
>    #include <dirent.h>
>    #endif
>
> Surely somebody has built kpathsea for MinGW, so it is a matter of finding
> the correct fix.

I do have a comment on using the pre-processor macro/s to determine
the system or system type. If you want a Windows 32 bit system, then
it's __WIN32__ and/or __WIN32 (the non-underscored counterparts are
an abomination); if you want to exclude Cygwin, then it's __WIN32__ &&
!__CYGWIN__. Mingw is plain Windows32, and thus covered by __WIN32__,
and there is typically never a good reason to use __MINGW32__ explicitly,
unless you're taking advantage of something specific in Mingw helper
libraries.

Regards,
Mumit