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

Greetings!  OK -- coming shortly.  Unfortunately, we've just heard
about a death in the family, and so are called out of state for a few
days.  It looks like the patch will have to wait for the weekend, if
that's ok.

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