Re: [Gcl-devel] Re: [Maxima] 5.9.0 release very close

[Camm Maguire]

Greetings!  OK, here is my patch, which works now with the newly
updated gcl CVS:

=============================================================================
--- maxima-5.9.0rc1/src/Makefile.am     Fri Aug 16 17:59:04 2002
+++ mn/src/Makefile.am  Mon Sep  9 18:04:02 2002
@@ -73,6 +73,22 @@
 clean: clean-gcl
 distclean: clean-gcl
 
+FORCE:
+
+binary-gcl/saved_maxima: FORCE
+       LISPTYPE=gcl ; export LISPTYPE ;\
+       GCL=$(GCL_NAME) ; export GCL ;\
+       j=$$($(RUNLISP) \
+               -x '(load "$(top_srcdir)/lisp-utils/defsystem.lisp")(funcall 
(intern "OPERATE-ON-SYSTEM" :mk) "maxima" :load :test t)' |\
+               grep Loading |\
+               grep file | \
+               awk 'BEGIN {a="$(shell pwd)"}\
+                       {gsub("\"","",$$NF);b=b " \"" a "/" $$NF "\""}\
+                    END {printf("(%s (list %s) %s %s )",\
+                         "compiler::link",b,"\"" a "/address@hidden"",\
+                         "\"(provide \\\"maxima\\\")\"")}') && \
+       $(RUNLISP) -x "$$j"
+
 binary-gcl/maxima:
        test -d binary-gcl || mkdir binary-gcl
        test -d binary-gcl/numerical || mkdir binary-gcl/numerical
intech19:/fix/t1/camm$ diff -u maxima-5.9.0rc1/lisp-utils/defsystem.lisp  
mn/lisp-utils/defsystem.lisp
--- maxima-5.9.0rc1/lisp-utils/defsystem.lisp   Fri Aug 16 17:58:56 2002
+++ mn/lisp-utils/defsystem.lisp        Mon Sep  2 14:01:45 2002
@@ -4182,6 +4182,7 @@
                          source-pname
                          :output-file
                          output-file
+                         #+gcl :system-p t 
                          #+CMU :error-file
                          #+CMU (and *cmu-errors-to-file*
                                     (component-full-pathname component
=============================================================================

A few comments:

1) Basically, gcl now has a function in the compiler package called
   'link' which takes a list of object filenames, a name of the final
   image, and a string of any optional post initialization code.  The way
   I got the list of these modules rfom the defsystem you are using may
   not be optimal.  In fact, I thought some modules like plot.o were not
   compiled in, but were available for loading at runtime.  Is this not
   true?  In any case, the release candidate seems to load everything.

2) Maxima now overwrites gcl's default sloop module.  The way I
   handled this was to refrain from initializing any gcl system
   modules with the same name as a module named in the list argument
   to compiler::link.  Such a work around is definitely necessary, but
   perhaps not foolproof at present.  Comments welcome.

3) It does seem the new image using the system C linker is a bit larger
   and slower than the one making use of non-dlopen relocations
   followed by save-system.  So the default build should probably
   remain as is for gcl.  On some platforms, however, as stated
   previously, we have no native relocation ability and must use the
   dlopen.  Here are my timings.  Please note that they were not
   completely reproducible, so conclusions may vary:


saved_maxima: (dlopen)
=============================================================================
-rwxr-xr-x    1 camm     camm      9402218 Sep 10 00:22 
src/binary-gcl/saved_maxima
Error summary:
Error(s) found in rtest15.mac: (4)

Expected failures (known bugs in this version of Maxima):
rtest15.mac: (4)

Timing:
real time : 10.020 secs
run time  : 9.540 secs
*** end of summary for tests-gcl.log

=============================================================================
saved_maxima: (static libbfd)
=============================================================================
-rwxr-xr-x    1 camm     camm     12027492 Sep  9 23:49 
src/binary-gcl/saved_maxima
Error summary:
Error(s) found in rtest15.mac: (4)

Expected failures (known bugs in this version of Maxima):
rtest15.mac: (4)

Timing:
real time : 11.190 secs
run time  : 10.630 secs
*** end of summary for tests-gcl.log
=============================================================================
maxima: (static libbfd)
=============================================================================
-rwxr-xr-x    1 camm     camm     11449496 Sep  9 23:46 src/binary-gcl/maxima
Error summary:
Error(s) found in rtest15.mac: (4)

Expected failures (known bugs in this version of Maxima):
rtest15.mac: (4)

Timing:
real time : 9.890 secs
run time  : 9.070 secs
*** end of summary for tests-gcl.log
=============================================================================

4)  What's with the remaining bug?  It would be very nice if we could
    have some test target to make which would return a trappable error
    code if the test produced a different list of errors than
    expected.

5) :system-p is needed for the saved_maxima target, but not the maxima
   target.  Doesn't hurt in either case.

6) Obviously the dependency of the saved_maxima target needs work.
   This is just meant as a working outline.

7) The initialization code for gcl still appears a bit delicate, and
   I'd like to clear that up.  There are 6 lsp source files which
   cannot be compiled -- some for obvious reasons, some, like
   cmpmain.lsp and autoload.lsp, are not clear to me.  Attempting to
   include cmpmain in compiled form breaks compilation -- the
   functions in cmpmain.lsp generate invalid function pointers to the
   functions they call in other files.  In any case, the strategy used
   for source-tree-less images via ld is to pack all .o files, with
   their .data appended in the usual fashion, into a libgcl.a now
   installed with the distribution.  The 6 uncompilable files are also
   installed.  compiler::link puts libgcl.a on the ld link command
   line to generate the raw_image.  The init code to the raw_image has
   been reworked to use ar to unpack gcl object files from libgcl.a
   for the purposes of initialization in a new image.

As always, comments welcome!


Take care,

James Amundson <address@hidden> writes:

> On Mon, 2002-09-02 at 22:40, Camm Maguire wrote:
> > Greetings, and thanks for looking into this.  
> > 
> > I have a solution, which is not particularly pretty, but which I can
> > submit in the form of a patch to src/Makefile.am after testing here
> > for a couple of days.  So if you can wait a bit, it would be
> > appreciated.  If not, I can apply the patch to the Debian package, and
> > we can shoot for the next release.
> 
> We can wait a little while longer. I will be interested to see what you
> have to do.
> 
> > This whole issue has brought up a couple of ideas, which may prove
> > important to future gcl development.
> > 
> > 1) Dr. Shelter chose to link the maxima objects into gcl via ld
> >    instead of (load ...), even when this would have been possible on
> >    i386 and sparc.  Perhaps this was just to make the build as general
> >    as possible.  But perhaps it makes a significant difference to
> >    gcl/maxima performance, as all those objects are out of the lisp
> >    core and linked into the static .text section of the executable.
> >    Hopefully I'll have some numbers on this soon.
> 
> Interesting. Please let us all know what you find.
>  
> > 2) Such a link operation could be straightforwardly aranged to occur
> >    within gcl itself, say (load ...)(link-noncore
> >    "filename")(init-image "filename" "saved_filename")(by), since a C
> >    compiler and its linker are guaranteed to be available where gcl
> >    is.  This would eliminate the biggest objection to the old build
> >    system IMHO, which was the necessity of having a gcl build
> >    directory around when building maxima.
> 
> Yes, I really think that would be much better than mucking around with
> the gcl build directory. It would make me much happier.
> 
> > 3) The right way to do this is to ship the bulk of gcl in a shared
> >    library, -lgcl.  Should save *a lot* of space in a multi-user
> >    environment too.  I've tried this, and there is some strange
> >    segfault error popping up, my guess due to some assumption that's
> >    being made in our memory management/gc about the fixed location of
> >    certain objects.  This may turn out to solve the mysterious troubles
> >    on the hppa port as well.  In principle, I can't see why we should
> >    have a problem with a -fPIC compile flag.  Anyone else?
> 
> It wouldn't be bad to have a static option as well. One advantage GCL
> has over Clisp and CMUCL is the ability to create a standalone
> executable. In the case where GCL is only being used for Maxima, the
> ability to ship a statically-linked executable is convenient.
> 
> --Jim
> 
> 
> 

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