4 ms·

Haven't used SBCL in a while, so just to confirm: is this a better alternative to SB-EXT:SAVE-LISP-AND-DIE?

• fisxoj 6y ago
  Without looking at the details, this work probably still uses something like that, under the hood. In mainline sbcl, dumping an executable with save-lisp-and-die will create an executable that depends on a few dynamic libraries and, if you use the ffi, whatever dynamic libraries you're using though that. With the already existing static-program-op in one of the cffi packages (grovel, maybe?), you can get an executable with all of the libraries linked through the cffi linked in staticly (you won't need those .so files when you distribute the executable) but it will still need a few dynamic libraries when run. Glibc and libm at least, I think. As I understand it, this work is attempting to remove even those last few dynamic dependencies so you can distribute the dumped executable and be done. So, better if you want simpler distribution at the cost of larger executables.
• zulu-inuoe 6y ago
  `save-lisp-and-die` is still how you do the image dump, but the process here is: 1. compile & load all lisp code 2. dump list of external symbols 3. save-lisp-and-die into a .core file 4. build new SBCL w/ symbols from step #2 linked in (using sbcl.o, which is the SBCL runtime) 5. run new SBCL, using the core from step #3 6. save-lisp-and-die into an executable edit. fixed formatting