gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] [Mail Delivery System <address@hidden>] Mail delivery failed


From: Camm Maguire
Subject: [Gcl-devel] [Mail Delivery System <address@hidden>] Mail delivery failed: returning message to sender
Date: 04 Jan 2002 16:35:30 -0500

A useful reply from a query I posted to comp.lang.lisp.  Forwarded
with permission! 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah
------- Start of forwarded message -------
To: Camm Maguire <address@hidden>
Subject: Re: "Fasload"
References: <address@hidden>
From: Peter Van Eynde <address@hidden>
Message-ID: <address@hidden>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: 30 Dec 2001 21:58:53 +0100

Camm Maguire <address@hidden> writes:

> Greetings!  I've taken on the task of maintaining GCL.  (The project

Congratulations. I admire your courrage :-)

> is currently setup at savannah.gnu.org, for those interested.)  I'd
> like to get the code working on as many platforms as possible,
> especially, the Linux architectures supported by Debian.  The only
> really non-portable piece, from what I can so far tell, is this bit
> about "fasloading".

If I remember correctly gcl converts the lisp code to a C stub, then
compiles the stub with gcc and then loads it into the running image,
correct?

If I were you I could convert the stuff towards using dlopen and
friends. Of course this doesn't work on all architectures and even
those that support it will be slightly upset about all the mmap's all
those libraries need :-(. To be honest I never understood the ld
trick gcl uses :-(

> My current strategy is to keep this basic design, but use the bfd
> library to try to get the elf relocations working portably. But over

Sounds good.

> the long term, I do wonder why it wouldn't be simpler just to compile
> objects as PIC code, and link them in as shared objects.  One will

Yep.

> have to decide how to handle the "lisp vector" traditionally appended
> at the end of the Elf file, but this should not be insuperable.

Beware of gc problems. gc-ing code normally is expected of a lisp
system :-(.

> 1) Am I overlooking something, i.e. is there a really good reason for
>    the existing "fasloading" mechanism which would necessitate keeping
>    it indefinitely?
> 2) In your experience working with Lisp (of which I have basically
>    none), do you have opinions/suggestions on how object loading
>    should best be accomplished?

The 'best' option IMHO would be to compile the code with gcc, and then
using just the code generated by gcc. Loading it directly into the
lisp image as a code-vector and using the boehm conservative gc to
manage the code and variables.

Oh, gcl has a pretty bad reputation when it comes to
ansi-standardness. comp.lang.lisp just seems to prefer to 'convert'
people to clisp/cmucl/sbcl instead of explaining why gcl just doesn't
work as expected. In the clocc project on sourceforge there is the
ansi-testsuite that might help you.

Good luck!

Groetjes, Peter

-- 
Groetjes, Peter

-- 
It's logic Jim, but not as we know it. | address@hidden
"God, root, what is difference?" - Pitr|
"God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd/


------- End of forwarded message -------

------- End of forwarded message -------



reply via email to

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