RE: [Gcl-devel] GCL on Cygwin

[Mike Thomas]

Hi Jim.

Thanks for your interest in GNU Common Lisp and, particularly, your interest
in the politics of the Windows version.

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

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

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

If you read over those emails again or search further, you will find that my
aim has been to produce a compiler which could be used to produce standard
Windows applications, so that third party developers can release packages
which appeal to average Windows users.  An example of such an application
package is the Windows Maxima computer algebra system.

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

Try the current CVS and source packages and let us know if there are further
problems.

| (And yes, after I
| finish this I'm going to have a good long yell at the GCC developers.)

Please don't yell at the developers.  Rather, try sending chocolate and
bananas or even bottles of Drambuie.  We wite better much more entertaining
emails when drunk and high on sugar.


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

Because I don't have the time or interest to support two Windows versions.
We would be pleased, I'm sure, if you were to volunteer to care for and feed
a Cygwin port.


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

Cheers

Mike Thomas.