[cmucl-imp] ASDF 2.016 released

[Raymond Toy]

On 6/8/11 2:14 PM, Faré wrote:
>
> If I have another wishlist for CMUCL, it would be self-enclosed
> application delivery into a single executable that includes the image.

If you had asked a year or so ago, I would have said definitely not. 
But now that I've changed how executables are created (no more huge
gross linker script), it's now much easier to maintain and actually even
works on solaris/sparc, which didn't have that before.  Now it's a
question of how stable I think it is.  I personally don't even build
custom images and just load up whatever I need.  Thus, I don't even use
the :executable feature at all either, other than an occasional test.

Don't know if I'd make that the default, but I wouldn't have any problem
with creating snapshots that included a single executable.  Well, that's
not quite right.  The executable would include the image, but the
unicode info is still stored out in a separate file.  Would that be ok? 
Might be possible to build an executable with that included too, but
I'll have to test that.
> SBCL, CLISP, CCL, ECL, LispWorks do it and are supported by XCVB and
> CL-Launch. Could CMUCL do it? That would tremendously simplify
> delivery of code.
>
> For extra brownie points, if you have a good story for a "linkkit"
> allowing to statically compile additional C libraries into the
> executable being delivered, that's would be wonderful. CLISP and ECL
> have it, SBCL notably doesn't. If CMUCL is similar to SBCL in that
What do you mean to statically compile in libraries since there are
usually no static libraries anymore, just shared ones?   If you dump an
image that includes other shared libraries, cmucl is supposed to reload
those libraries automatically when the image is started again.  That
used to work, but I haven't tested that in ages.  Would that be ok?  Or
do you really mean statically linked?
> regard, you might have to have some magic linker script and function
> annotations to ensure that magic functions are located at an address
> known to Lisp code despite new code being linked into the .text and
> .data segments. Typically, you'd either ensure the proper objects
> files are linked first, or you'd create a magic segment(s) different
> from .text and/or .data, that starts at a magic address, in which to
> compile the stuff that the Lisp image will expect to be at a known
> address.
This is kind of how cmucl creates its executable images.  The main thing
are that the address of two magic trampoline functions and the addresses
of the various spaces are specified to the linker when creating the
executable image.   Not exactly sure how to extend that right now, but I
suppose it's possible.

Ray