Re: [Gcl-devel] GCL on Cygwin

[Jim Babcock]

Camm Maguire wrote:
> Jim Babcock <address@hidden> writes:
> > 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:
<snip>

I tried that with unexw32.c from Emacs 21.3, and a lot has changed in that
file since it was copied, including identifiers that are referenced from
other files. So it'll take a bit more than that. Older Emacs versions may
be of use here.

> 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

Autoconf should be able to test for Cygwin without the user specifying
(though I haven't done much with autoconf before.)

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

Right, it failed later presumably because it was absent.

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

<varargs.h> is also included from h/gnuwin95.h. Should probably just remove
that line outright. Binutils and gmp3 also refer to it, but only if stdarg
is unavailable, so they're ok.

> > Next up, a sed problem for a change. In unixport/makefile, is this nice bit
> > of obfuscated sed code:
[snip sed script]
> 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.

$(CC) contained an include path, -I/usr/include/somethingorother. Since CC
and CFLAGS are set automatically, they might contain forward slashes. In a
sed command, a forward slash means to start the next field, unless it's
part of an escape sequence. The solution given here is to put a backslash
(escape) before every forward slash.

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

Ok, but that should be mentioned somewhere on the site.

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

It still appears all over the place. A quick grep -R found at least one
instance in each of these files, as of 2.7.0-24. (Many of these look like
automatically generated files, though I'm not sure.)
        configure.in        h/386-bsd.defs
        h/FreeBSD.defs      h/gnuwin95.defs
        h/hp300-bsd.defs    h/linux.defs
        h/mac2.defs         h/mp386.defs
        h/ncr.defs          h/NetBSD.defs
        h/NeXT30-m68k.defs  h/NeXT32-i386.defs
        h/NeXT32-m68k.defs  h/OpenBSD.defs
        h/solaris.defs      h/sun2r3.defs
        h/sun3-os4.defs     h/sun3.defs
        h/symmetry.defs