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

[James Amundson]

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