[Top][All Lists]

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

Re: [Gcl-devel] HEAD Maxima and HEAD trad GCL

From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] HEAD Maxima and HEAD trad GCL
Date: Fri, 09 Jan 2004 21:14:57 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.5) Gecko/20031006

Camm Maguire ?????:

James Amundson <address@hidden> writes:

On Thu, 2004-01-08 at 13:08, Camm Maguire wrote:


"Vadim V. Zhytnikov" <address@hidden> writes:

Yes, but my resolution is not of kind I like.
Replace Maxima's defsystem.lisp by older version -
beginning of May 2003 or earlier.

Vadim, could you please have mercy on me and explain what confluence
of the newer defsystem and windows gcl is causing all this?  I must
have missed it in your earlier posts.

If there are real problems with the gcl 2.6.2 ansi build on windows and
the only thing that is keeping traditional gcl 2.6.2 on windows from
working with Maxima is defsystem.lisp, then we can *certainly* fix
defsystem.lisp. It is my stated desire to move Maxima to the ansi gcl
build as soon as possible. That does not mean I want to create an
artificial stumbling block over what looks like a very small problem.

The only changes in defsystem.lisp are various portability conditionals.
If the May 2003 version works (I think Vadim means revision 1.9. If not,
he should say so), then the changes required to get the current
defsystem.lisp to work should be trivial.

Thanks James!  Its good to be able to fall back on this.  I still
would like an explanation of the problem if possible -- doesn't sound
too difficult to fix.  Am too busy right now to diagnose it myself.

Take care,

Sorry for prolonged silence (every January is a hard time to me
with respect to spare time).

Something is wrong with GCL + mingw + Maxima CVS.
Maxima GCL build stops with the following error message
Source file "C:/msys/1.0/home/vadim/maxima/src/C:/msys/1.0/home/vadim/maxima/src/j/numerical/slatec/dbesi0.lisp" and binary file "binary-gcl/numerical/slatec/dbesi0.o" do not exist.
See bogus /j/ in .../maxima/src/j/numerical/... source path.
This symbol may vary - it may be /l/ or /5/ or something.
Behavior is 100% reproducible with any particular GCL build
but changes if I rebuild GCL with some modifications.
In this case make will stop at other source file.
Further behavior may be also different.  You may get
succesfull Maxima build after 5-6 repetitive make
invocation (each time make compiles some more
10-15 source files and stops with similar error message
at another place) or get into loop since make stops
at the same source file.

The only "resolution" I have - replace Maxima defsystem
by older version. Then Maxima build goes flawlessly.
I'd like to know who is the real troublemaker.
Maybe we hit some subtle GCL+mingw bug.

     Vadim V. Zhytnikov


reply via email to

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