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

[Camm Maguire]

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.

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.

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.

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?

More later,

Take care,

James Amundson <address@hidden> writes:

> On Thu, 2002-08-22 at 23:54, Camm Maguire wrote:
> > Greetings!
> > 
> > James Amundson <address@hidden> writes:
> 
> > > > 2) The only issues of which I am aware regard the new build system,
> > > >    which I believe relies on the lisp system's 'save-system' call or
> > > >    analogous to do the final link of the compiled objects into the
> > > >    resulting executable.  The old system used the system linker ('ld')
> > > >    for this step, to avoid breaking builds on platforms for which gcl
> > > >    could not relocate object code by itself.  Gcl is in the process of
> > > >    implementing  native relocation on all supported platforms, but as
> > > >    of this time, i386 coff, (e.g. Windows), mips, alpha, ia64, and
> > > >    hppa do not have this functionality.  Can one use ld with the new
> > > >    build system?
> > > 
> > > Ah. I was unaware of this issue. I would certainly like the Maxima GCL
> > > build to be as portable as possible. We can change the way the link is
> > > done under GCL. I just spent a some time reading the old Makefile.
> > > Unfortunately, it is not entirely clear to me what it does, even though
> > > I am a Makefile professional (a long story...)
> > > 
> > > Can you tell me roughly how the linking should work?
> > > 
> > 
> > Yes, roughly the .lisp is compiled to .o and .data as usual by gcl.
> > Instead of then running gcl again to load the .o and save-system, ld
> > is run on the .o files to create a raw_maxima, and then an
> > initialization command is read by raw_maxima to initialize its modules
> > and save-system to saved_maxima.  If you need more detail, please let
> > me know.  I can pre-test for you on a relevant box before your
> > release, if you'd like.
> 
> OK. I am going to admit defeat here. I have now spent several hours on
> this problem with very little progress to show for it. The Maxima build
> is currently defined by the defsystem description. I am to the point
> with defsystem and Lisp where I think I understand what happens with
> files that are compiled, loaded and evaluated in the presence of
> eval-when and defsystem options. I cannot say the same for the gcl build
> using the linker. In my experiments, I tried compiling the files with
> defsystem, then using a "make saved_maxima" in the gcl/unixport
> directory using the compiled object files. I do not understand how to
> take care of the files that are simply loaded, however. There are
> probably other things I don't understand, also. (From a configuration
> management standpoint, I find the ld procedure highly frightening, but
> perhaps I misunderstand what really needs to be done.) The bottom line
> is that I do not understand how to recreate the system created with
> defsystem using the gcl ld process. If someone can show me how to do it,
> we can try to incorporate it as an option in the build.
> 
> The good news is that the current build works with Windows and MinGW.
> Clisp also works under Windows, so we have decent coverage there.
> 
> --Jim
> 
> 

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