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