[cmucl-imp] ASDF 2.016 released

[Raymond Toy]

>>>>> "Fare" == Far  <Far> writes:

    >> I started to move the shell script into C; that doesn't look too hard,
    >> but then I realized that for an executable to be able to create another
    >> executable image, you need to also have lisp.a, which is basically the
    >> run time.  For the executable to be self contained, that would also have
    >> to be in the executable.
    >> 
    >> At this point I'm giving up.  I don't really want to store lisp.a inside
    >> the executable too.
    >> 
    >> Not sure what to do at this point.  But I will add the necessary
    >> function to load up unidata into core in case someone wants that.
    >> 
    Fare> Interesting. Well, for delivery, I would be satisfied with not
    Fare> including the lisp.a in the executable -- it is only require when
    Fare> you're using the compiler for development, at which point it's OK to
    Fare> not embed lisp.a (or unidata) into the image. After all, the CLISP

The only time you need lisp.a is when you create an executable image.
Otherwise, it's just wasting space.

    Fare> linkkit isn't embedded in the clisp executable itself, so you'll be no
    Fare> worse off than other implementations. But yes, that sucks. Of course,
    Fare> you could conceivably "unlink" the current process image (or its
    Fare> executable as found with /proc ?) into a platform-specific .o file to
    Fare> link at a static address, but while a cool hack, it's not necessary.
    Fare> Didn't ELK kind of do that, though?

I think so.  Isn't that also how emacs used to (still does) work too?
I'm pretty sure gcl still does something like that.

Ray