[Gcl-devel] 2.6.1-8

[Camm Maguire]

Greetings!  Just a brief note on a few developments:

1) I've renamed the lsp and cmpnew files, and the init_* functions in
   o, largely in response to function name conflicts when building
   axiom with compiler::link.  The idea is that we reserve as much of
   the init_.... function namespace as possibly for the user.  In o/,
   this is done by init_* -> gcl_init_*; in lsp and cmpnew we take for
   ourselves functions of the name init_gcl_*.  Remember we did
   similarly with pcl_ and clcs_ prefixes when putting together the
   ansi build.  At some point we should homogenize to gcl_pcl_ and
   gcl_clcs_, but this is left for a future date.

   If for example a user has a module named hash, GCL will call the
   init function init_code if :system-p is not set, and init_hash
   otherwise.  The former can be linked in just fine with fasload, but
   not with ld, as init_code will be multiply defined.  On dlopen
   systems without fasload, (ia64, alpha, mips(el), hppa), one has to
   resort to ld linking via compiler::link at present, and therefore
   must have uniquely named compiled lisp modules.

   As before, we hope the absence of fasload on these platforms is
   temporary.  Its really a question of bfd supporting its function
   bfd_get_relocated_section_contents on these machines.  As there are
   really only three open source apps using GCL at present which need
   this portability (for purposes of inclusion in standard
   distributions like Debian), the present setup is manageable, but
   requires someone (like me) patching the build process (e.g. for
   maxima, acl2, and axiom) to use compiler::link when appropriate.
   It would be great if this was completely transparent to the user.
   We're not that far away.  Consider the following patch for axiom
   for instance:

-       @ (cd ${OBJ}/${SYS}/bin ; \
-         echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) 
(user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+#      @ (cd ${OBJ}/${SYS}/bin ; \
+#        echo '(progn (gbc t) (load "${OUT}/makeint.lisp") (gbc t) 
(user::spad-save "${SAVESYS}"))' | ${LISPSYS} )
+       @ (cd ${MNT}/${SYS}/bin && \
+         echo '(setq si::*collect-binary-modules* t)(setq x 
si::*system-directory*)(load "${OUT}/makeint.lisp")(setq si::*system-directory* 
x)(compiler::link (remove-duplicates si::*binary-modules* :test (quote equal)) 
"$(SAVESYS)" "(setq si::*collect-binary-modules* t)(load 
\"$(OUT)/makeint.lisp\")(when si::*binary-modules* (error 
si::*binary-modules*)(setq si::collect-binary-modules* nil si::*binary-modules* 
nil)(setq compiler::*default-system-p* t)(gbc t))" 
"$(OBJ)/$(SYS)/lib/sockio-c.o $(OBJ)/$(SYS)/lib/cfuns-c.o 
$(OBJ)/$(SYS)/lib/libspad.a" nil)' | ${LISPSYS})

   I've added a facility for collecting a list of fasloaded binary
   modules for use in compiler::link.  when
   si::*collect-binary-modules* is set to t, si::*binary-modules* will
   have a list of loaded .o files.  compiler:link takes this list as
   its first argument, and compiles using ld a 'raw' image made up of
   all gcl objects (in libgcl.a et.al) and these specified .o files.
   It then runs the raw image with the gcl init script as input
   (init_gcl.lsp), appending to that file the third argument of
   compiler::link.  This basically just loads the user init file
   again.  When the load of the .o files is attempted, GCL notices
   that they've already been compiled in, and a running of their init
   sequence is executed instead.  We collect the binary module list
   again to make sure that no actual fasloads have been performed, and
   then save the system via unexec. The second argument is the output
   file, the fourth argument are extra C libraries needed for ld, and
   the last is a flag specifying whether to explicitly initialize the
   user .o files, or to let the fasload->init redirect do it
   automatically instead. 

   So in principle, we could make save-system perform these steps on
   non-fasload systems, *if it can collect user input/initialization
   code* to be fed again to the raw image.  It may be possible to
   instruct the reader to make a copy of input as it is parsed, in
   which case the above patch would be obviated.

   The problem of course in on multiple cycles of load, save, exec.
   All user .o files must be found in their original locations at each
   save invocation, and the binary-module list must not be tampered
   with.  In addition, the system-p flag must be set, most easily via
   compiler::*default-system-p*. 

   Personally, I'm not sure that greater transparency is worth the
   effort at present, considering that the machines in question appear
   to be rarely used, the application load is (currently) small, and
   that we can hope for bfd improvements.  But this is how it might
   go.

   In any case, I'd appreciate feedback on the naming conventions of
   our installed files.  I haven't modified the gcl-tk files for
   example, as they always appear to be fasloaded, but one might want
   to compile these in as well too someday.  We could use some
   standardization. 

2) Compressed info file reading should be working now.  I've removed
   the extra set of uncompressed info files from the Debian package.

3) There is a persistent gcc bug on ppc which will not allow
   compilation of new_init.c with full optimization.  Furthermore,
   there appears to be a highly image specific bug in strip on that
   platform as well.  I've added workarounds.

4) I've started work on a temporary alternate mirror site (very much
   in progress) to be found at http://people.debian.org/~camm/gcl.
   I'll add a link on our main page and try to incorporate Matt's
   instructions when this is complete.  When ftp.gnu.org becomes
   available again, we'll transfer this location.

Take care,



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