Subject: [Gcl-devel] Re: [Maxima] 5.9.0 release very close
From: Camm Maguire
Date: 20 Sep 2002 18:38:51 -0400
Hi James! Can you please commit this modification to the alt-link
stuff?
Take care,
Camm Maguire <camm@enhanced.com> writes:
> 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 <amundson@fnal.gov> 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 "/$@\"",\
> > > + "\"(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 <amundson@fnal.gov> 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 camm@enhanced.com
> > > ==========================================================================
> > > "The earth is but one country, and mankind its citizens." -- Baha'u'llah
> > > _______________________________________________
> > > Maxima mailing list
> > > Maxima@www.math.utexas.edu
> > > http://www.math.utexas.edu/mailman/listinfo/maxima
> >
> >
> >
>
> --
> Camm Maguire camm@enhanced.com
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
>
> _______________________________________________
> Gcl-devel mailing list
> Gcl-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
--
Camm Maguire camm@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah