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

[Camm Maguire]

Greetings!

OK, Vadim, I think you are right here.  I've committed another attempt
at a fix.  Please comment if you still see problems.

Take care,

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

> 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
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah