Re: [Gcl-devel] GCL on Cygwin

[Camm Maguire]

Greetings!

In general, I think it would be useful for you to post your full
configure and make output you've attained thus far, together with a
'cvs diff -u' output.

Jim Babcock <address@hidden> writes:

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

Are you assuming this is the case from the changes, or have you tried
it yet?  We only access this file via its unexec function api, and as
long as the prototype hasn't changed, the interals used by emacs
should be just fine.

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

I think you mean configure, which is produced by autoconf. We can
address this at the end -- for now --enable-machine= should work.
What are you using here?


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

Did save.c fail to compile?  I don't think it is absent if you are
getting a raw_gcl.exe, as the linker needs it to build this
executable.  If you do have a raw_gcl.exe, what is the result of 'cd
unixport && raw_gcl.exe ./ <foo' ?

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

Yes, please remove varargs.h.

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

Yes, or you can use some other character as separator.  Sed will use
whatever is right after the s.    In general, though, CC should just
contain the compiler name.  It is set to gcc on Linux.  CFLAGS takes
-I flags and the like.  The sed command uses '#' as separator here for
this reason.

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

Agreed -- we are quite behind in this regard.

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

Thanks for this.  Most of these machines are no longer in active use.
In such cases, I usually leave things just as they were when the files
were last working in case someone ever wants to look at them again.
We need only remove the flag where newer gcc is in active use.

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