[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MINGW build
From: |
Paul Kienzle |
Subject: |
Re: MINGW build |
Date: |
Mon, 23 Sep 2002 21:30:23 -0400 |
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
- MINGW build, Paul Kienzle, 2002/09/22
- MINGW build, John W. Eaton, 2002/09/23
- Re: MINGW build, Mumit Khan, 2002/09/23
- Re: MINGW build,
Paul Kienzle <=
- Re: MINGW build, Paul Kienzle, 2002/09/23
- Re: MINGW build, Paul Kienzle, 2002/09/24
- Re: MINGW build (kpathsea), Paul Kienzle, 2002/09/24