Re: MINGW build

[Doug Warner]

Have you looked at the ACE (http://www.cs.wustl.edu/~schmidt/ACE.html) OS
abstraction layer?  It abstracts dlopen, thread and process
creation/management, and other interfaces across many Unix variants and
Win32.

Doug Warner

----- Original Message -----
From: "Paul Kienzle" <address@hidden>
To: <address@hidden>
Sent: Monday, September 23, 2002 7:30 PM
Subject: Re: MINGW build


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