Re: [Gcl-devel] GCL on Cygwin

[Camm Maguire]

Greetings, and thanks for giving this a whirl!

Jim Babcock <address@hidden> writes:

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

My suggestion:

1) Retrieve the unex???.c file used in cygwin emacs from the emacs
   source
2) copy to o/
3) Append the following:

=============================================================================
/* All of the above is from the emacs-20.7 file.  This comment and the
   following are added for gcl.  Also we changed the above (near "for
   gcl") we make the NEW_SECTION_H executable since it will have code
   in it.  NEW_SECTION_H (nn).sh_flags |= SHF_EXECINSTR;
   
   Partly synchronized with Emacs HEAD of 2004-04-12 by Magnus Henoch.
   The files themselves are no longer mmap'ed, but memory is allocated
   with mmap, and everything is written to the new file at the end.
*/
#ifdef UNIXSAVE
#include "save.c"
#endif
=============================================================================

4) Place in your .h file  the following:

#define UNIXSAVE "unex???.c"

   Are you using gnuwin95.h? Might be best to start with 386-linux.h.
   I suggest this, and rename to cygwin.h for starters, as with the
   .defs file, and using --enable-machine=cygwin as an option to
   configure



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

As Mike already said, this can go in your .h file.

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

Have to have an unexec at present to build gcl.

> 
> 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 suggest removing varargs completely, as is done for the other
platforms.  It is no longer needed in the code.

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

Great!  Mike, if you agree, lets just add the third arg in all cases
in CVS head.  Please advise if you wish me to do so.


> 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" >$@
> 

I'm afraid I'm a bit confused here, do you mean '/' or '\'?  Why does
this not fail on mingw?  Do you have a full path in $(CC)?  If so, I
think this is the best place for a solution -- configure should set CC
to something like 'gcc -Wall ....' and let the PATH variable specify
the directory. 

We depend on gnu make in other places, so no worry there.

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

OK, here you may need a tiny bit of work.  There are three main memory
areas of whose ranges GCL needs to be aware:  1) the heap (where
malloc starts, 2) the C stack and 3) the 'static area', where
addresses of global C variables live.  One also needs to know whether
these areas grow up or down.  A simple little C program can easily
determine these, by just printing out the values of subsequent
mallocs, local C variable addresses and global C variable addresses.

Once this is in hand, you need to double check the NULL_OR_ON_C_STACK
macro, and the DBEGIN macro, for both of which configure produces
defaults.  

DBEGIN is likely wrong, my guess.  Specifically, the page macro in
page.h, which calculates how many pages the page containing a given
address lies above DBEGIN, is returning a negative number, which when
cast to unsigned is too large.

I suggest passing --enable-debug to configure at this stage.  You can
then run gdb on raw_gcl.exe, break at add_page_to_freelist, and see
what is going on.

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

This should be an easy port given cygwin's closeness to linux.

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

We have a temporary binary distribution site at

http://people.debian.org/~camm/gcl
http://www.cs.utexas.edu/users/boyer/gcl

ftp.gnu.org was down, and we've been waiting for the 2.6.2
finalization to resume binary uploads there.

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

-fwritable-strings should be removed from the flags, as I've done at
 least for Linux.  It is not needed.

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

Take care,

> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah