[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] GCL on Cygwin
Re: [Gcl-devel] GCL on Cygwin
Wed, 09 Jun 2004 17:04:20 -0400
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
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).
1) Retrieve the unex???.c file used in cygwin emacs from the emacs
2) copy to o/
3) Append the following:
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
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
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.
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
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
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.)
Re: [Gcl-devel] GCL on Cygwin, Jim Babcock, 2004/06/09