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.
Interesting. Well, for delivery, I would be satisfied with not including the lisp.a in the executable -- it is only require when you're using the compiler for development, at which point it's OK to not embed lisp.a (or unidata) into the image. After all, the CLISP linkkit isn't embedded in the clisp executable itself, so you'll be no worse off than other implementations. But yes, that sucks. Of course, you could conceivably "unlink" the current process image (or its executable as found with /proc ?) into a platform-specific .o file to link at a static address, but while a cool hack, it's not necessary. Didn't ELK kind of do that, though?
This all reminds me how cl-launch does it, being a shell script that embeds code that it can either use (after eval'ing it) or dump into shell scripts for delivery. Gah.
-#f