|
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 ?????:
Greetings! James Amundson <address@hidden> writes:On Thu, 2004-01-08 at 13:08, Camm Maguire wrote:Greetings! "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 <address@hidden> <address@hidden>
[Prev in Thread] | Current Thread | [Next in Thread] |