gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Camm Maguire
Subject: Re: [Gcl-devel] Re: [Maxima] 5.9.0 release very close
Date: 23 Aug 2002 00:54:09 -0400

Greetings!

James Amundson <address@hidden> writes:

> On Fri, 2002-08-16 at 17:14, Camm Maguire wrote:
> > Greetings!  No objections, rather congratulations!  Somewhere in the
> > back of my mind I envisioned synchronizing the next gcl release with
> > this maxima release, though I suppose its not really necessary.  
> > 
> > 1) Would such a synchronization be desirable?
> 
> That's a good question. I have an arguments both for and against
> coupling.
> 
> For: It is in Maxima's interest that new releases of GCL precede new
> releases of Maxima so that Maxima can be fully tested with the newest
> version of GCL. It is in GCL's interest that new releases of Maxima
> precede new releases of GGL so that GCL can be fully tested with the new
> version of Maxima. The only logical compromise is to have simultaneous
> releases.
> 
> Against: Having a program and the language in which it is written so
> tightly coupled that one cannot be changed without the other is
> obviously a bad thing.
> 
> Although the second argument is somewhat exaggerated, I think it wins
> out over the first. At the very least, I don't think we *need* to couple
> 5.9.0 with a new release of GCL; Maxima builds just fine with 2.4.3
> right now.
> 
> (Actually, I have one minor issue with the current release. 2.4.3
> reports its version number as "2.5.0." I anticipate that could cause
> confusion in bug reports. I apologize for not reporting this bug
> sooner.)
> 

Thanks for the heads up here!  I agree that we shouldn't make major
compromises to synchronize, especially in the present case.
Personally, I think 2.5.0 is looking pretty good.  We've managed to
keep the cvs tree capable of building most gcl projects pretty
consistently, much to my amazement!  We're trying to decide now what
to commit to finishing before 2.5.0 is released.


> 
> > 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.

take care,

> Thanks,
> Jim
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]