RE: [Gcl-devel] GCL on Cygwin

[Mike Thomas]

Hi Jim.

Thanks for the reply.

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.

I haven't got time to help you out in depth at the moment so this is a
fairly brief reply.

Jim B. wrote:

| 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).

See Camm's separate reply on this.

| 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__

Thanks.  The best place for those macros is in a cygwin configuration header
in the "h" directory eg "h/cygwin.h" which would be copied by the
configuration process (ie running "configure) to become "h/config.h".  You
could probably start one by copying bits of "h/linux.h", "h/mingw.h" and
"h/gnuwin95.h".

| 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).

This has nothing to do with emacs integration.  It is essential for saving
out a running lisp system.  I agree, it will be hard.  I think Camm has also
separately addressed this issue.



| 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

I haven't had a chance to think about this.


| 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];

Or this.


| 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.

Or this.


| 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.

Must be a problem with your Cygwin setup.  For example, on mine:

========================================================
$ /C/cvs/stable/gcl-2.6.1/unixport/saved_gcl.exe
GCL (GNU Common Lisp)  2.6.1 CLtL1   May 27 2004 13:30:35
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  LGPL
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

>
========================================================

however this is a minor part of the issue.  I am not aware of a generic
Windows application that can deal with the "/cygdrive/c" or "/C/" style path
format without taking special (and statistically unwarranted) steps to do
so.  For example, next time you are logged into your Cygwin Bash shell try
this:

  notepad /c/junk.txt

Putting all this aside, why not use the convenient sh script provided by the
GCL configuration eg at my Cygwin prompt:

==========================================================$
/C/cvs/stable/gcl-2.6.1/bin/gcl
GCL (GNU Common Lisp)  2.6.1 ANSI   May 27 2004 13:30:35
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  LGPL
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

>
==========================================================

| I may look into that closer.

Thanks.


|
| > | 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.

I agree it is annoying, however, this is done so that if the batch file is
started in a Windows command shell it does not leave the environment
variables it sets and uses in the parent shell after it is finished.

If you know another way to solev this ploblem please let me know as it has
been a vexatious issue for a long time.

That batch file is really expected to be started from a desktop shortcut
anyway.


| 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.

See Camm's separate email.


| >> 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.

I haven't noticed any spam in either CLISP or Corman.  I believe that the
beautiful candelabra motif in CLISP can be turned off with a system variable
in the CLISP initialisation file.


| Plus
| it doesn't make native binaries.

Corman does, and a lot more besides.

Cheers

Mike Thomas.