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

[Vadim V. Zhytnikov]

Hi Camm!

I'm sorry for long silence but my main job rendered me
incapable of doing anything constructive to GCL/Maxima
for whole month.

I decided not to apply any (build-symbol-table) patches
to GCL CVS since I'm not quite sure that we need this
symbol tables.  In any case we can easily do this
as soon as we realize their necessity.  The only thing
I've noticed is that if we build usual saved_gcl without
(build-symbol-table) before (save-system) then
later saved_pcl build fails with obscure error message.

I've almost finished editing gcl.texi to comply with
modern texinfo.  It is turned out quite straightforward
but long and routine work.


Camm Maguire:
> Greetings!
>
> "Vadim V. Zhytnikov" <address@hidden> writes:
>
>
> > Camm Maguire пишет:
> >
> > > Hi Vadim!  Your patch looks fine.
> > >
> > > 1) Is there anything different about the resulting build with or
> > >   without the initform, short of the 'building...' message, as far as
> > >   you can tell?
> >
> > I don't see any difference except new images are bigger (about 1Mb).
> > BTW, how can I see that symbol table is _really_ present in
> > saved_<something>?  Do I need gdb?
>
>
> This is the easiest way.  Just gdb saved_..., and do 'l main.c:1'
>
>
> > > 2) I'd appreciate if we could not modify the default linux.{h,defs}
> > >   until discussing a bit further.
> > > 3) You can commit the makefile patches if you want, to facilitate
> > >   experimentation. 
> >
> > Maybe we should add some new configure option.
> > Something like --without-symbol-table.
> > Without this option all images are build with or
> > without symbol table according to appropriate .defs.
> > With --without-symbol-table no symbol table
> > in any saved_<...>?
>
>
> Well, keep in mind that the raw_gcl symbol table must always be built
> if you want to load binary objects!  Or maybe I am misunderstanding
> you.  There are two issues -- gcl's symbol table for object
> loading/relocation, and a set of *debugging symbols* in the final
> image, conventionally kept in .stabs sections I think.  The idea of a
> configure option is not bad though.  What it would have to do to keep
> gdb symbols, however, is to alter the makefiles to use ld for the final
> link at each image production stage.  Rebuilding the
> relocation/loading symbol table could be done as in your patch, but is
> likely unecessary, and is now confirmed by your test to bloat the
> image.  The compiler just won't spit out symbols that can't be found
> int the compact raw_gcl image.  We should probably even make certain
> new modules, like destructuring-bind and loop, external to this symbol
> table build, perhaps by making them 'load on demand' objects like
> readline.o.  
>
> Take care,
>
>
> > > thanks!
> > >
> > > "Vadim V. Zhytnikov" <address@hidden> writes:
> > >
> > >
> > >
> > > > This is a multi-part message in MIME format.
> > > > --------------080605030101030203060402
> > > > Content-Type: text/plain; charset=KOI8-R; format=flowed
> > > > Content-Transfer-Encoding: 8bit
> > > >
> > > > Camm Maguire пишет:
> > > >
> > > >
> > > > > If it wouldn't be too much trouble, could you post the diff first?  
> > > > >
> > > > > My original concern was in running ansi images in gdb -- and the
> > > > > answer there seems to be using the system ld for the final link, as
> > > > > even with a working native reloc code, we don't import the .stabs
> > > > > debugging section of the objects, so those pieces of code effectively
> > > > > become black boxes to gdb.  We could change this in the future, or
> > > > > provide an option to do so, but for now only developers should be
> > > > > interested and the easiest thing is to provide a make target which
> > > > > uses ld.  So the symbol table building here is not an issue.
> > > > >
> > > > > Beyond this, regarding the compile time/runtime initialization -- this
> > > > > again is apparently not a problem, and I think I now know why.  The
> > > > > lisp compiler is very careful not to compile in named references to
> > > > > any functions that aren't available in raw_gcl.  All other function
> > > > > links are arbitrarily named and connected to the proper function at
> > > > > load time.  So in short, the symbol table built when initializing
> > > > > raw_gcl should suffice, and it apparently does or else all hell would
> > > > > break loose when loading pcl objects as part of the ansi build.  
> > > > >
> > > > > So in sum, I don't think we need to build the symbol table again -- in
> > > > > fact, it would just be a gratuitous waste of memory space, adding in
> > > > > symbols which the loader would never need.  But I could be wrong, and
> > > > > would like to see your diff in any case.
> > > > >
> > > > > Take care,
> > > >
> > > >
> > > > Actually patch is very simple (see attachment):
> > > > ----------------------------------------------------------------
> > > > diff -uNr gcl-2.5.0-orig/clcs/makefile gcl-2.5.0/clcs/makefile
> > > > --- gcl-2.5.0-orig/clcs/makefile        2002-06-28 08:42:52 +0400
> > > > +++ gcl-2.5.0/clcs/makefile     2002-08-17 15:58:23 +0400
> > > > @@ -1,11 +1,13 @@
> > > >
> > > > +-include ../makedefs
> > > > +
> > > > #LISP=../pcl/saved_gcl_pcl
> > > >
> > > > compile: ${LISP}
> > > > 	echo '(load "package.lisp")(load "loading.lisp")(jamie-load-clcs 
> > > > :compile)' | ${LISP}
> > > >
> > > > saved_full_gcl: ${LISP}
> > > > - 
> > > > echo '(load "package.lisp")(load "loading.lisp")(jamie-load-clcs 
> > > > :compiled)(system::save-system "saved_full_gcl")' | ${LISP}
> > > > + 
> > > > echo '(load "package.lisp")(load "loading.lisp")(jamie-load-clcs 
> > > > :compiled)$(INITFORM)(system::save-system "saved_full_gcl")' | ${LISP}
> > > >
> > > > -include ../makedefs
> > > >
> > > > diff -uNr gcl-2.5.0-orig/pcl/makefile gcl-2.5.0/pcl/makefile
> > > > --- gcl-2.5.0-orig/pcl/makefile 2002-08-06 19:43:42 +0400
> > > > +++ gcl-2.5.0/pcl/makefile      2002-08-17 15:58:59 +0400
> > > > @@ -1,5 +1,7 @@
> > > > # makefile for making pcl -- W. Schelter.
> > > >
> > > > +-include ../makedefs
> > > > +
> > > > #  Directions:
> > > > # make -f makefile.gcl compile
> > > > # make -f makefile.gcl saved_pcl
> > > > @@ -18,7 +20,7 @@
> > > >         echo ${SETUP} '(pcl::compile-pcl)' | $(LISP)
> > > >
> > > > saved_gcl_pcl:
> > > > - 
> > > > echo ${SETUP} '(pcl::load-pcl)(si::save-system "saved_gcl_pcl")' | $(LISP)
> > > > + 
> > > > echo ${SETUP} '(pcl::load-pcl)$(INITFORM)(si::save-system 
> > > > "saved_gcl_pcl")' | $(LISP)
> > > >
> > > > clean:
> > > >         rm -f *.o *.fn *.exe *.dll saved_gcl_pcl
> > > > -------------------------------------------------------------------
> > > >
> > > > We just insert $(INITFORM) right before (si:save-system ...).
> > > > The value of $(INITFORM) is defined in h/<arch>.defs and may
> > > > be either  equal to (si::build-symbol-table) or empty.
> > > > But maybe we should make $(INITFORM) subject to new configure
> > > > option, say --enable-symbol-table ?
> > > >
> > > > Best wishes,

--
     Vadim V. Zhytnikov

      <address@hidden>
     <address@hidden>
     <address@hidden>
    <address@hidden>