Re: MINGW build

[Paul Kienzle]

On Mon, Sep 23, 2002 at 03:39:55PM -0500, Mumit Khan wrote:
> 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.

I don't think there will be much need for POSIX functionality, or I wouldn't
be trying this!

> 
> > 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.

I would ideally like it to be included via oct.h so that oct-files can
assume it is already defined.  For the moment moving it is sufficient.

> 
> > 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.

And nothing we can do about it unless we put all of our names in our own
namespace?

> 
> > 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.

Thanks.

> 
> >
> > 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.

It turns out that this code is redundant --- it was handling the case where
erf/erfc aren't available, but they are always available from libcruft.

Regardless, I've stripped it down to a minimal program which causes the
error. Compile the following under the september mingw release using gcc -O2

        void (*call)(char *);

        double
        xerf (double x)
        {
          (*call)
            ("erf (x) not available on this system");
        }

You need the function indirection to cause the error.  Adding a return 0.0
at the end of the function removes the problem.  Feel free to submit this
to the apporpriate mingw list.

> 
> > 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.

math.h defines it (lo-mappers.cc contains the line just before) and I 
guess cmath undefs it (it contains #undef isnan).

By moving

  #include <cmath>
  bool xisnan (double x) { return isnan(x); }

before <config.h> I was able to get it to compile.  Perhaps it is

  #define CXX_ISO_COMPILIANT_LIBRARY 1

or

  #define __NO_MATH_INLINES 1

which is causing problems.  

It is too difficult to eliminate <cmath> since <complex> includes it.

I tried a number of things after <config.h> such as using

  #define _GLIBCPP_USE_C99
  __gnu_cxx::isnan

without success.

> > 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.

Nope.  We do need the capabitity for intercepting floating point exceptions
and user interrupts eventually.  Suggestions where to look for info?

> > 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.

Yeah, I discovered that earlier.  I also discovered the kbhit function.
I have a patch in process. Any idea which of kbhit and _kbhit is preferred?
>From the headers I'm guessing it's _kbhit.

> 
> >
> > => 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.

Yes.  I think it will be easy enough to borrow code from the tcl interpreter
or whatever to do a system call.

> > 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.

kpathsea's configure is a bit of a mess.  I'm really hoping someone else
has sorted it out for later versions of mingw since it didn't build
out of the box for me.  I couldn't find any hints easily on google though.

> 
> Regards,
> Mumit

dlopen and dlsym will need to be replaced or emulated.  Do you have code
for this?

Thanks,

        - Paul