gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] troubles bulding Maxima with latest GCL CVS


From: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] troubles bulding Maxima with latest GCL CVS
Date: Tue, 18 Jun 2002 19:03:33 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.0.0) Gecko/20020526

Camm Maguire пишет:
Greetings!

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


Hi!

I've troubles in building Maxima with latest GCL CVS.

With Maxima 5.6 something wrong with Makefiles.
I have not identified the real source of the trouble but
if you look at makefile in Maxima /src dir you can see

LISP=saved_ansi_gcl

Which is wrong since full path to saved GCL image is required.
Previously there are no such line and make looked for
gcl in $(PORTDIR)/saved_....



OK, I think I've fixed this.


Nope ;-)  Now maxima modules are compiled OK but build stops later
trying to build Maxima image complaining about missing
COMMON_LISP-USER package.
Reason: maxima modules are compiled with saved_gcl which is now
new big GCL while maxima image is tried to build with traditional image.
So maxima 5.6 build fails unless we use --disable-ansi for gcl.
Why don't you adopted the scheme I proposed. It seems to be logical
to me and ensures _complete_ compatibility with any old style
builds. I mean - old names raw_gcl and saved_gcl refer to old
style lisp images. All new style images acquire some other names.
The only necessary extra steps with this scheme is to modify
make command which builds /bin/gcl script and change
corresponding make install.


With Maxima 5.9 trouble is entirely different. If I use
latest GCL CVS compiled with --disable-bfd then
everything is fine. But is bfd is enabled then
I've got the following error
---------------------------------------------------
;      - Loading binary file "binary-gcl/comm2.o"
Loading binary-gcl/comm2.o
start address -T 898b000 Finished loading binary-gcl/comm2.o

;    - Compiling module "evaluator"
;      - Loading binary file "binary-gcl/mlisp.o"
Loading binary-gcl/mlisp.o
Error in FUNCALL [or a callee]: This file was dumped with FASD version 0 not 2.

Fast links are on: do (use-fast-links nil) for debugging
Broken at CONDITIONS::CLCS-LOAD.  Type :H for Help.
 1 (Continue) Retry loading file "binary-gcl/mlisp.o".
 2 (Abort) Return to top level.
dbl:>>


I see this too, but

1) I'm confused.  I thought you said in your previous email that you
   could build amxima and pass all tests with the new stuff?

No confusion actually. I had this clean build _before_ you made large bfd related commit.


2) I'm having trouble debugging this, as all the new images are
   lacking (gdb) debugging symbols, due no doubt to the way we're
   building them.  Compiling with just -g, raw_gcl of course can be run
   find in gdb.  saved_trad_gcl is then made from raw_gcl at the lisp
   level, and also retains debugging symbols as shown when running
   under gdb.  (i.e. one has line number and source file information,
   etc.)  saved_maxima is made from saved_gcl (and in some cases
   raw_gcl) at the lisp level and likewise retains debugging symbols.
   But clcs/saved_full_gcl, pcl/saved_gcl_pcl, and
   unixport/saved_ansi_gcl all are missing debugging symbols, not only
   blocking my investigation of this issue, but also indicating
something fishy to me about the way we're building these images.
   I have a debugging reloc file, which basically does both the new
   bfd and the old hand coded one and compares, halting at
   mismatches.  No mismatches are found, but the error you see
   persists.  Also, building maxima 5.9 with saved_trad_gcl using bfd
   works fine.  So we seem to have an issue in the combination of bfd
   with the new inages.

   One thing I notice at saved_maxima and at saved_trad_gcl creation
   is the "Building raw symbol table" notifier.  This does not appear
   when building the new images.  These symbols are generated via the
   lisp function build-symbol-table, which must be getting called
   somewhere before save-system, though I cannot find it right now.  I
   don't think we are invoking this in the new image saves.  In
   general, the reloc code counts on the symbol table being generated
   at compile time, and statically available at run time.  I think,
   though, that the old reloc code could also build the table in case
   it was not initialized at runtime.  the new code does not yet have
   this capability, so perhaps I'll try adding this.  But to be sure,
   I need to be able to run gdb, which I can't now.  Can you help
   here, Vadim?

Take care,

To be honest I don't quite understand how can I really help.
I know that the gdb is but I newer practiaclly used it
in my life.  What is FASD version 0 or 2?  Can you find a
place in the code where this FASD check is performed?
Maybe this helps. I could probably take a look at the new
maxima build scheme and play a bit with it (like applying
build-symbol-table and so on) but I'll be off for
two days or more, sorry.

Best wishes,

Vadim





reply via email to

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