[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: Vadim V. Zhytnikov
Subject: Re: [Gcl-devel] troubles bulding Maxima with latest GCL CVS
Date: Sun, 22 Sep 2002 20:53:08 +0300
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru-RU; rv:1.0.0) Gecko/20020526

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:

"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

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
Take care,


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

This is a multi-part message in MIME format.
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

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)

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

        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


reply via email to

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