[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Gcl-devel] STABLE, WINDOWS: read_fasd1() and alloc_relblock()

From: Billinghurst, David (CALCRTS)
Subject: RE: [Gcl-devel] STABLE, WINDOWS: read_fasd1() and alloc_relblock()
Date: Tue, 20 Apr 2004 22:50:00 +1000

I started to look into some of this, but got sidetracked
when one of my molars decided to split.  Ouch.
> Using the Maxima 20040219 source package (both with and without
> ignore-errors) and stable CVS GCL (which contains my fixes of last night):
> 1. GCL/gcc 3.3.1/binutils 2.14.90 builds Maxima and passes tests both with
> and without ignore-errors - I haven't been able to replicate the
> "ignore-errors" path mangling bug so that looks good.

With this combination maxima builds and passes tests.  Haven't tried 

> 2. GCL/gcc 3.3.3/binutils 2.15.90 still causes the Maxima crash.  It now
> crashes consistently (which is also good news) while loading
> "binary-gcl/specfn.o" so if we still have the fortitude and time we can
> probably track it down.
> The problem occurs in the Maxima source file "src/clmacs.lisp", function
> "aset-by-cursor" called in "fillarray":

I played mix and match.  I have:
 - gcc-3.3.1 and gcc-3.3.3
 - CVS gcl from last Friday built with both gcc's

By a process of elimination, I found that the maxima crash above
occurs when the maxima routine clmacs.lisp is compiled with gcc-3.3.3
It does not depend on the gcc used to compile gcl

That isn't the end of the problem, as the compiled maxima crashed in the 

I can use a gcc-3.3.3 compiled gcl to build a working maxima if I use 
gcc-3.3.1 for the maxima build. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]