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

[Camm Maguire]

Greetings, and thanks!  My patch was just to alter the link part after
the compile, so to get the new stuff working, you have to add the
following to your current cvs:

        LISPTYPE=gcl ; export LISPTYPE ;\
        GCL=$(GCL_NAME) ; export GCL ;\
+       $(RUNLISP) \
+       -x '(load "$(top_srcdir)/lisp-utils/defsystem.lisp")(funcall (intern 
"OPERATE-ON-SYSTEM" :mk) "maxima" :compile :verbose t)' && \
        j=$$($(RUNLISP) \
                 -x '(load "$(top_srcdir)/lisp-utils/defsystem.lisp")(funcall 
(intern "OPERATE-ON-SYSTEM" :mk) "maxima" :load :test t)' < /dev/null |\

Take care,


James Amundson <address@hidden> writes:

> Camm,
> 
> Thanks very much for your patch. I think we are close, but not quite
> there yet. I have installed your patch to defsystem and a slightly
> modified version of your patch to Makefile.am. My modifications:
> 
> 1) It builds "maxima" not "saved_maxima". Which linking procedure is
> used is selectable at configure time. Configure with
> --enable-gcl-alt-link to use your new linking procedure.
> 
> 2) I added a couple of "< /dev/null"'s because otherwise an error make
> the process appear to hang.
> 
> I couldn't make it work for me, but I don't have time to repeat the
> details at the moment. I don't understand how the files would get
> compiled in this scenario. Maybe I missed something.
> 
> Sorry for the brief reply. More later.
> 
> 
> --Jim
> 
> On Mon, 2002-09-09 at 23:29, Camm Maguire wrote:
> > 
> > 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
> > _______________________________________________
> > Maxima mailing list
> > address@hidden
> > http://www.math.utexas.edu/mailman/listinfo/maxima
> 
> 
> 

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