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

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