Re: new attempt GNUstep on cygwin

[Fred Kiefer]

Over the weekend Riccardo Mottola and I spend a few hours with GNUstep 
on Cygwin. We failed as did anybody else who tried recently, but at 
least we would like to share the things we found out and hopefully the 
next attempt will then get further.

Cygwin
======
We used the gcc4 packages (gcc 4.3.4) as the standard gcc packages have 
a broken libffi (even when you add all the scattered pieces you will 
need for that).
Riccardo will send a detailed list of all the Cygwin packages he has 
installed for GNUstep.

As noted earlier it is crucial that you don't have spaces in the paths 
used by Cygwin. We just created a new home directory and redefined the 
HOME environment variable.

Make
====
Make uses somewhat strange file extensions for Cygwin compiled files 
ended up being called .c.o and .m.o, no problem as the linker expects 
that naming convention. It is only when compiling a file manually that 
you will have to remember to rename it (and move it into the correct 
directory).

Base
====
We had problem with the default locale on Cygwin. It has LANG set to 
"C.UTF-8", this isn't supported in the GSLanguageFromLocale() function 
in base, which obviously is a bug. It is easy to work around this by 
setting LANG to "C".

Gui
===
We have some hack in NSBitmapImageRep+JPEG.m that was added specifically 
for Cygwin at some point in time but now breaks the compilation. We need 
to find out whether that modified JPEG library is still in circulation. 
If not we can just remove this code otherwise we need to add a configure 
check for this special JPEG library.

Back
====
you need to run configure --enable-server=win32 if you want the native 
display and why wouldn't you want that?
The compilation of gscolors.c failed for me. Strange enough it worked 
when done manually, but without the -o switch. Most likely this is a gcc 
bug and this was the place where I found out about the strange 
extensions and directory names.
winpbs.m has a missing #include, we need to add this.

Execution
=========
We tried to run all the test code in base and gui. For some reason the 
test environment wont detect test cases that just break with a 
segmentation fault, that way it is hard to say how much of the tests 
actually run correctly. In base teh NSRunLoop test never returned, we 
had to kill it.
Simple command line tools seem to run, as they already get used when 
compiling gui and back.
Any real gui application and more complex tools seem to segmentation 
fault rather early. The computer with the backtrace is a few hundred 
kilometres away, Riccardo will have to provide the exact backtrace, but 
it wasn't very helpfull.

I think the next step should be to recompile our own libobjc as most 
likely this is the source of the problem. We didn't have the time for 
this on the weekend and it is unclear at what time any of us will touch 
Cygwin again.