I will check this as soon as possible.

I'm trying to build the latest release of GCJ (MinGW's is rather old, 3.4.x, whereas the latest GCC seems to be 4.2.x).  If I can confirm that the break happens in a recent compiler, I'll bug the GCC folks, but right now I think it more likely that MinGW is just stale.

Jeremy



On 4/3/06, Peter Graves <peter@armedbear.org> wrote:
On Sat, 1 Apr 2006 at 16:43:59 -0500, Jeremy Shute wrote:
> Hi,
>
> I just got CVS ABCL to build using MinGW's GCJ!  I didn't expect it to be as
> easy as it was:
>
>    1. Get MinGW (w/GCJ obviously)
>    2. Get libiconv developer files from the gnuwin32 project, drop the
>    contents in your MinGW directory.  While you're there, pick up the binaries
>    for the DLL's.
>    3. Get CLISP (I used Cygwin's CLISP and altered the
> build-abcl.lispfile to point to the Cygwin path of MinGW GCJ).
>    4. Compile.
>    5. Put lisp.exe alongside the gnuwin32 libiconv DLL's, and put the
>    *.lisp files under ./org/...
>    6. Fire it up!
>
> Now I'm trying to get SLIME to work.  I reduced the problem down to where I
> could determine it's not SLIME's fault.
>
> I put a simple file, test.lisp:
>
> (defun test () (print "TESTING 1 2 3"))
>
> ...in my C drive.
>
> Armed Bear Common Lisp 0.0.9.1+
> Java 3.4.2 Free Software Foundation, Inc.
> GNU libgcj
> Low-level initialization completed in 0.016 seconds.
> Startup completed in 7.579 seconds.
> Type :HELP for a list of available commands.
> CL-USER(1): (defparameter *x* (open "c:/test.lisp"))
> *X*
> CL-USER(2): *x*
> #<FILE-STREAM {1CB5F00}>
> CL-USER(3): (stream-element-type *x*)
> CHARACTER
> CL-USER(4): (load "c:/test.lisp")
> Error loading c:\test.lisp at line 1 (offset 0)
> Debugger invoked on condition of type STREAM-ERROR:
>
> Process inferior-lisp exited abnormally with code 5
>
> I have tried quite a few combinations of this.  I can read-line from the
> opened stream, but I simply cannot load anything.
>
> Ideas???

It looks like a bug in GCJ. Unlike Sun and IBM Java, GCJ's ZipFile
constructor apparently returns a non-null ZipFile object even if the
file being opened is not a valid zip file.

As a temporary workaround, you can change the code around line 93 of
Load.java like this:

         ZipFile zipfile = null;
-        try {
-            zipfile = new ZipFile(file);
-        }
-        catch (Throwable t) {
-            // Fall through.
+        if (!filename.toLowerCase().endsWith(".lisp"))
+        {
+            try {
+                zipfile = new ZipFile(file);
+            }
+            catch (Throwable t) {
+                // Fall through.
+            }
         }

This should let you load .lisp files, but it's clearly not a complete
solution. I'll try to take a more careful look at this issue later this
week.

You might want to report the GCJ bug to the GCJ folks.

Thanks!

-Peter