[cmucl-imp] ASDF 2.016 released

[Raymond Toy]

On 6/8/11 3:19 PM, Faré wrote:
>> 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.
> That would be great.
>
>>  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.
> Not so great without it, unless the file is available at standard
> locations in all Linux distributions as in /usr/share/misc/unicode.gz
Heh.  My openSuSE 11.4 machine doesn't have that file.  But even if it
did, it wouldn't work.  The unicode data file is a custom file created
from Unicode.txt and a bunch of other unicode files.  The only option I
can see would be to include the contents of that file into the image.  I
think that's possible.
>> 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?
>>
> I really mean statically linked.
> Currently, CFFI and friends produce plenty of .so files for wrappers.
> I don't want to chase a zillion Lisp-specific .so files;
> that totally defeats the "delivery into one executable file" strategy.
> Also, some less-known or fast-changing C libraries might be good
> candidate for inclusion as static libraries rather than dynamic libraries.
I'll have to think about that.   That would take some work to integrate,
but might fit in fairly easily with the executable support.
>> This is kind of how cmucl creates its executable images.
> Oh, I didn't realize you already had this feature. Sweet.
Fred came up with the original idea, but at the time he only knew how to
do it by creating a custom linker script.  I talked to him about it and
figured out gcc with a few special arguments would do the same thing. 
That allowed me to extend the idea to work on solaris/sparc and even Mac
OS X.
> Did you also fix that age-old bug whereby cmucl parsed -eval arguments
> passed the end of the lisp image arguments?
This only prints out 42 now:

cmulisp -noinit -eval '(print 42)' -- -eval '(print pi)'

Is that what you mean?  Or did you mean something else?
>
> Can you tell me which things they are and point me to the linker magic?
> I think I could port the trick to SBCL...
The C side of the stuff is in src/lisp/elf.c and src/lisp/mach-o.c and
src/lisp/save.c, with a little bit of help from the lisp side in
src/code/save.lisp.  elf.c and mach-o.c dump the three spaces into valid
elf or mach-o object files.

The script that does the linking is src/tools/linker.sh.  It takes the
arguments created by save.c and does the right thing on the various
supported architectures and calls gcc in the right way to tell the
executable that an image is attached and to append the three spaces onto
the end of the C executable.

Hope this helps.  If you have questions understanding what's going on,
just drop me a note.

Ray