[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] troubles bulding Maxima with latest GCL CVS
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] troubles bulding Maxima with latest GCL CVS |
Date: |
19 Jun 2002 17:42:10 -0400 |
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