NT, mingw32

["Howard Chu" <hyc@highlandsun.com>]

Well, we're making progress on the mingw32 front. There have been several
little problems along the way. Currently we have a couple of the libraries
(liblutil and liblber) building as DLLs, and we've hacked together a working
slapd. Right now we're cleaning up the hacks, adding tests to configure.in,
etc...
	The gcc compiler (and all the tools) in the mingw32 distribution uses the
DOS-standard line terminator. The tools in the cygwin distribution are too
braindead to strip the CR off input lines. So, using cygwin bash, the result
of any command substitution that invokes a DOS or mingw32 command includes a
trailing ^M in the result, which makes most shell scripts very unhappy. We
tried the mingw32 compiler because it was already at 2.95, while the cygwin
20.1 distribution only had 2.91, but we are now using a cygwin-patched 2.95
gcc.
	There's a problem with libtool which will eventually need to be fixed: the
normal behavior on a Unix system is for libtool to generate both a shared
library and a static library. On NT, libtool generates a .dll file and a .a
file, but the .a archive is actually just an import library for the shared
library. The actual static library won't be generated if a shared library is
being made. The question is how should these archives be named, since both
an actual static library and the stub import library will probably be
needed, and they both use the same ".a" suffix.
	There's a file in liblutil that's meant for the MSVC message compiler.
Since we figure that a mingw32 user won't have access to MSVC, we are
checking the message compiler output into our CVS tree, and I expect to do
the same in the OpenLDAP tree when we're ready to integrate the changes. The
situation is analagous to configure vs configure.in: we check both into CVS,
and if you have autoconf, you can rebuild configure yourself. Otherwise, you
can just use the configure script that's already provided.
	There's a problem with build order in the slapd directory. Currently all
the backends are built before the main slapd binary, and this is the order
things must occur for regular, static builds. For dynamic objects, however,
NT requires files to be fully resolved at link time. This means that any
backend built as a module that references symbols from the slapd binary
needs the slapd binary to already exist, i.e., the slapd binary must be
built first, instead of last. We're going to try working around this one by
creating an import library that defines the interesting symbols exported
from slapd. The source for this import library will be checked into CVS, and
the import library will be built first, then the backends, and then the
slapd binary.

Just wanted to give you the status, in case anyone else was thinking about
leaping down this trail.