Problems getting Cygwin/MinGW to work

[Stephen Brandon]

Hi all,

I'm having first crack at getting MusicKit et al to compile
on Win32 via GNUstep. But first, I have to get GNUstep to
compile... Now I have seen from the lists that some people
are actively working on Mingw code, so SOMEONE must have got
past these hurdles!

I've read all I can on the mingw site and the various
related mailing lists, but can't see anything major that I
have done wrong.

Here's my sequence of steps so far. Comments welcome.

1. clean installed win2000 on machine. Smallish C drive,
bigger D drive. To make things easy to access from my
preferred OS (Linux) I use FAT filesystems (against my
better sysadmin judgement).

2. downloaded cygwin latest version from redhat.com. Ran it
and got it to install everything including icon on desktop.
Did not download source code to any particular packages
 - it installed to d:/cygwin

3. downloaded latest mingw, and used the gzip and tar
packages from cygwin, to untar it into d:/mingw

4. added d:\mingw;d:\cygwin to path on Win2000 (order is
important)

5. edited d:/cygwin/etc/profile to have the following path:
PATH="/cygdrive/d/mingw/bin:/usr/local/bin:/usr/bin:/bin:$PATH"

6. used cvs to get GNUstep latest version, following
instructions on GNUstep.org annon cvs, putting the "core"
module into d:/ROOT/core

7. tried to do a "./compile-all" in base, but found a
problem with the make.exe utility provided by mingw (looked
like it was not following symbolic links as provided by
Windows Shortcuts). Also in compile-all I have to change the
check for the user logged in as root, to also allow
"Administrator".

8. copied the make.exe from cygwin/bin into mingw/bin --
this now works somewhat better!

9. Find that some paths still not being found by some
utilities... "Foundation/Foundation.h" not found when trying
to compile the first ".m" file. Wonder if it's related to
the problem with mingw's make.exe not finding paths...

10. Also need to get hold of libxml and ffcall to help
things along (reported by ./configure in core/base). These
fail to compile in my environment. (failure messages not
included at this point).

11. Also need to get hold of libtiff in order for core/gui
to compile (of course it won't actually display anything,
but we're not too worried about that - we just want it to
compile). (this does not compile either).

12. Suspect that shortcuts are not being treated as soft
links by the compiler. :-(  So that would explain why
Foundation/Foundation.h is not found. Have now simply
duplicated the d:\ROOT\core\base\Headers\gnustep\base folder
as d:\ROOT\core\base\Headers\gnustep\Foundation, and left
the old alias that was called Foundation where it was. It
has now started to compile .m files :-)

13. removed 2 imports from UnixFileHandle.m: #include
<netdb.h> and #include <sys/ioctl.h> since they were not
found on mingw

14. realised after looking at GNUmakefile that there should
be a check done for ifeq ($(GNUSTEP_TARGET_OS), mingw32) to
conditionally compile WindowsFileHandle.m instead of
UnixFileHandle.m. But GNUSTEP_TARGET_OS looks like its some
long path ending in ".../cygwin". So I set the makefile
variable to mingw32 just before the check, and hope for the
best.

15. now it looks like I am getting somewhere... some .m
files are compiling. But it all explodes when compiling
GSCompatibility.m, with the NSByteOrder.h complaining about
not recognising "gsu32". I do a search and find
GSConfig.h.in in the headers which should dynamically define
gsu32 from the configure script... but it looks like this
has not happened (no GSConfig.h to be found) and make has
never complained about not being able to find it. Uh.

16. It's funny -- any time there's an error, exactly the
same step is tried again by the compiler/make. Has anyone
seen this before?


Any guidance VERY welcome.
Cheers,
Stephen Brandon
stephen@brandonitconsulting.co.uk