Re: [Gcl-devel] GCL on Cygwin

[Jim Babcock]

Mike Thomas wrote:
> Could you in future please keep GCL email on the developers list?    That
> way there is a public record of the development process which hopefully
> avoids repetition of earlier work.

Whoops. Most lists set Reply-To on all outgoing messages to point to this 
list, but this one doesn't, and I didn't notice. So this message is a 
repost of what I originally posted, and I will respond to the rest of 
Mike's message separately.

Mike Thomas wrote:
> Thanks for your interest in GNU Common Lisp and, particularly, your
> interest in the politics of the Windows version.

Well, I decided to jump in and see how close I could get it to compiling.
Most of the issues were outright bugs which only by chance failed to break
the other targets. Unexec is still a problem, though; I tried merging in
the unexw32.c but that didn't work at all (though it might be possible to
get it working, I really don't know what's going on in that code).

Ok, first Cygwin issue, unixtime.c. Very simple:
diff -u -r1.21 unixtime.c
--- unixtime.c  13 Apr 2004 02:58:11 -0000      1.21
+++ unixtime.c  8 Jun 2004 14:51:28 -0000
@@ -48,6 +48,11 @@
  #  define ATT
  #endif

+#ifdef __CYGWIN__
+#      define NO_SYSTEM_TIME_ZONE
+#      undef USE_INTERNAL_REAL_TIME_FOR_RUNTIME
+#endif
+
  #if defined __MINGW32__ || !defined NO_SYSTEM_TIME_ZONE

  #  ifdef __MINGW32__

Next issue, and definitely the hardest one, is unexnt.c. Rather than
dwelling on it, I slashed, burned and stubbed. I don't want EMACS
integration (I'm a vim user). Probably going to have to come back to this
later though.

Next issue: utils.c gets both <varargs.h> (through config.h) and
<stdarg.h>, and it gets them in the wrong order. Both define macros with
the same name, so whichever is included last undeclares the macros of the
other. Whoops! As a hack, I moved <stdarg.h> after "include.h" when
__CYGWIN__ is defined, but since the problem will affect other ports as
well, this is only a placeholder for a real solution.
diff -u -r1.10 utils.c
--- utils.c     17 Feb 2003 16:50:21 -0000      1.10
+++ utils.c     8 Jun 2004 15:16:45 -0000
@@ -1,7 +1,12 @@
  #include <string.h>
+#ifndef __CYGWIN__
  #include <stdarg.h>
+#endif
  #include <stdlib.h>
  #include "include.h"
+#ifdef __CYGWIN__
+#include <stdarg.h>
+#endif

Next issue is unixport/rsym_nt.c: conflicting types for main(). Protoize
says it should have a char **envp. Well, thanfully calling conventions are
nice and resilient, so adding it but not referencing shouldn't do any harm.
diff -u -r1.7 rsym_nt.c
--- unixport/rsym_nt.c  13 Jan 2003 07:26:03 -0000      1.7
+++ unixport/rsym_nt.c  8 Jun 2004 15:24:48 -0000
@@ -10,7 +10,7 @@

  struct lsymbol_table tab;

-int main(int argc,char *argv[])
+#ifdef __CYGWIN__
+int main(int argc,char *argv[], char **envp)
+#else
+int main(int argc,char *argv[])
+#endif
  {
      char buf[1000];
      char *in = argv[1];

Next up, a sed problem for a change. In unixport/makefile, is this nice bit
of obfuscated sed code:
cat $< | sed \
     -e "address@hidden@#(`cat ../majvers`.`cat ../minvers`) `date`#1" \
     -e "address@hidden@#`cat ../minvers | cut -f2 -d.`#1" \
     -e "address@hidden@#`cat ../minvers | cut -f1 -d.`#1" \
     -e "address@hidden@#`cat ../majvers`#1" \
     -e "s/@LI-CC@/\"$(CC) -c $(FINAL_CFLAGS)\"/1" \
     -e "address@hidden@#\"$(CC) -o \"#1" \
     -e "address@hidden@#\" $(LD_LIBS_PRE) -l$* $(LD_LIBS_POST)\"#1" \
     -e "address@hidden@#\"$(O3FLAGS)\"#1" \
     -e "address@hidden@#\"$(O2FLAGS)\"#1" \
     -e "address@hidden@#\"address@hidden"#1" >$@
...which, after variables full of slashes are substituted in, is completely
invalid. The obvious fix is with makefile functions. However, this will not
port to non-GNU make.

diff -u -r1.64 makefile
--- makefile    26 May 2004 02:22:55 -0000      1.64
+++ makefile    8 Jun 2004 19:47:36 -0000
@@ -100,11 +100,11 @@
        -e "address@hidden@#`cat ../minvers | cut -f2 -d.`#1" \
        -e "address@hidden@#`cat ../minvers | cut -f1 -d.`#1" \
        -e "address@hidden@#`cat ../majvers`#1" \
-      -e "s/@LI-CC@/\"$(CC) -c $(FINAL_CFLAGS)\"/1" \
-      -e "address@hidden@#\"$(CC) -o \"#1" \
-      -e "address@hidden@#\" $(LD_LIBS_PRE) -l$* $(LD_LIBS_POST)\"#1" \
-      -e "address@hidden@#\"$(O3FLAGS)\"#1" \
-      -e "address@hidden@#\"$(O2FLAGS)\"#1" \
+      -e "s/@LI-CC@/\"$(subst /,\/,$(CC)) -c $(subst
/,\/,$(FINAL_CFLAGS))\"/1" \
+      -e "address@hidden@#\"$(subst /,\/,$(CC)) -o \"#1" \
+      -e "address@hidden@#\" $(LD_LIBS_PRE) -l$* $(subst
/,\/,$(LD_LIBS_POST))\"#1" \
+      -e "address@hidden@#\"$(subst /,\/,$(O3FLAGS))\"#1" \
+      -e "address@hidden@#\"$(subst /,\/,$(O2FLAGS))\"#1" \
        -e "address@hidden@#\"address@hidden"#1" >$@

  saved_%:raw_% $(RSYM) init_%.lsp raw_%_map \


Unfortunately, it won't finish without the unexec-related and memory
management stuff working. It does with:
/usr/src/gcl-cvs/gcl/unixport/raw_pre_gcl.exe \
/usr/src/gcl-cvs/gcl/unixport/ -libdir /usr/src/gcl-cvs/gcl/ < foo
Unrecoverable error: Address passed to add_page_to_freelist beyone \
MAXPAGES.

But in any case, it's certainly a lot closer to compiling on Cygwin than it
was before, and many of the issues

>> Invoking the
>> executable directly, it crashes with:
>>   address@hidden bin]$ ./gcl
>>   export: C:/usr/local/bin:: bad variable name
>>   exec: /C/BIN/Devel/GCL/lib/gcl-2.6.1/unixport/saved_gcl.exe: not found
>> (It sees the Unix-style path and panics.)
>
> This is appropriate behaviour for a Windows application.  Perhaps you
> could write yourself a Bash script based on the batch file, converting
> paths into Windows format with cygpath?

Most Windows programs work fine without this; gcl is the only one I've seen
which didn't see the paths pre-converted. I may look into that closer.

>> Invoking it through the batch file, it opens a separate window!
>> Not exactly suitable for batch compilation. This can be partially fixed 
>> by taking the 'start' out of the batch file, but already it's
>> rediculous; it's not behaving at all like a Unix program.
>
> That's because it's a Windows program.

So? Invoking a batch file guarantees an available terminal, so there's no
reason to create another one.

>> The GCC maintainers have collectively lost their minds and started
>> pulling out everything which isn't explicitly in the standards
>> documents. Until a fork comes around to stop the madness, you need to
>> work around their idiocy. In particular: they've removed <varargs.h> in
>> 3.3, and they've removed -fwritable-strings in 3.5. The varargs.h
>> problem can be worked around by copying the header from an older
>> version, and stdarg.h should be used anyways, but assuming you're
>> passing -fwritable-strings for a reason, major changes are urgently
>> needed to fix that problem.
>
> Try the current CVS and source packages and let us know if there are
> further problems.

http://ftp.gnu.org/gnu/gcl/ only goes up to 2.5.3 (though there are LINKS
to newer versions in that directory, they're all broken.) I eventually gave
up trying to find a tarball and checked it out by CVS.

Still using varargs.h, which means no compiling with GCC 3.3 or later
without manually editing system headers. This is a problem for everyone.
-fwritable-strings is still there, too, which isn't a problem yet but which
will break everything when gcc 3.5 comes into use.

>> Anyways, I'm off trying other lisps. I'll be back in awhile to see how
>> things are.
>
> Corman Lisp is an excellent Windows Common Lisp compiler and relatively
> cheap.  Otherwise I suggest you try Linux to obtain a Unix Lisp system.
> If you seriously want to use Cygwin, try CLISP as it is also a classic
> Common Lisp system.

Tried it, and the amount of spam in the output was simply rediculous. Plus
it doesn't make native binaries.