Re: [Gcl-devel] GCL on Cygwin

[Camm Maguire]

Greetings, and thanks for your interest in GCL!

Jim Babcock <address@hidden> writes:

> After failing to compile on Cygwin, I looked through the old mailing lists
> to see what's been said about supporting Cygwin. Apparently, the reasoning
> for not supporting Cygwin is that the MinGW port is good enough for Windows
> users, and that a Cygwin program would be hard to package. These are both
> false.

The only obstacle to a cygwin port are the missing human resources,
i.e. just one person wou has such a machine and would be willing to
maintain the build, with of course substantial email support from
people using other systems.  Would you consider volunteering?  If so,
please let me know and I will give you some hints on how to proceed.
Cygwin should be quite close.


> 
> I'm using 2.5.3,
> 

You will be much happier with

export CVSROOT=:ext:address@hidden:/cvsroot/gcl
export CVS_RSH=ssh
cvs -z9 -q co -d gcl-2.6.2c2 -r Version_2_6_2c2 gcl

We have already addressed the varargs and -fwritable-strings issues in
this version, soon to be released in tar form.

> The MinGW port is completely useless to me, as a Cygwin user. 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.)
> 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.
> 

Were you to take this on, your build would be much more similar to the
existing Linux builds, which are the most stable, and need no
graphical support.

> Distributing a Cygwin program is actually quite easy, because no one
> expects you to make or distribute binaries. In the Windows world people
> expect installers, but Cygwin is part of the Unix world, including the
> mentality; Cygwin users have no problem compiling themselves. And if it
> compiles, it's likely to be integrated into Cygwin's package management
> system, where it will be easily available.
> 

This is fine, but one does need a somewhat stable development
environment to minimize the maintenance overhead.

> Now, as far as actual portability issues, I ran into three. One of them is
> a critical issue which will affect every version very soon,.
> 
> 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. (And yes, after I
> finish this I'm going to have a good long yell at the GCC developers.)
> 

This has already been addressed.

> Ok, now the Cygwin-specific stuff.
> 
> The biggest problem is unixsave.c, which, well, I haven't a clue what to do
> with it. I got rid of unexnt.c, since that was obviously wrong and had
> compilation issues galore, but unixsave.c in general is a problem: it's
> extremely nonportable. How did you manage to get that working on MinGW?
> 

All that is needed here is to copy the unexec???.c file used in Cygwin
emacs into place and append the 3 or so lines at the end of unexelf.c
as indicated by the comment.

> There's also an issue with unixtime.c, but there was a fix on this list
> some time ago and it's easy enough to stub out. I'm not sure why it's not
> in.

Details here would be appreciated.  It would seem either the unix or
the windows versions should work, no?

> 
> Anyways, I'm off trying other lisps. I'll be back in awhile to see how
> things are.
> 

clisp should be available, but please be aware that it will likely be
considerably slower, as, unlike GCL, it does not compile to native
code, but rather runs interpreted.

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