7.1.2 Method Compatibility

Not all dumping methods work with all implementations either. The following table summarizes the situation. And of course, don’t mix methods! For example, do not attempt to dump the ASDF way if your code includes a call to dump.

Clon  (1)(2)(3)(4)(5)
ASDF  (1)(2)(4)

Dumping with both Clon and ASDF should work with CLISP in theory, but the current trunk (2.49) seems to have a problem with its command-line in dumped images. Its is possible to work around it by putting all command-line options after a -- separator, as for regular sessions (see Delivering Scripts). This issue has been reported at https://sourceforge.net/p/clisp/bugs/745/.

Please note also that standalone CLISP executables continue to recognize lisp-specific command-line options, when they are prefixed with --clisp-. Hence, you should obviously avoid defining options by those names.


Dumping an ECL image with Clon is not supported because of the way ECL works. In short, ECL requires every single Lisp file to be compiled to a system object file first, so you would need to know all the Lisp files involved, and I mean, all: all systems, all dependencies, etc. ASDF, on the other hand, has this information, so the ASDF method is much preferred.

Another difference between ECL and the other Lisp compilers is that it doesn’t require a particular function as the entry point for your executable, but instead relies on having code to execute directly at the toplevel of some file. Clon helps a little bit with this by making the dump macro expand to a call to the specified function. That way, you can still have a more or less portable file including a call to dump, should you choose to call ECL’s c:build-program all by yourself.

Finally, note also that Clon has some peculiar bootstrapping requirements with its setup sub-system. These requirements seem to cause problems with ASDF’s way of dumping executables in ECL, so in order for it to work properly, your own system depending on Clon needs to include an explicit dependency on ‘net.didierverna.clon.setup’ first, as shown in the example above, as well as in the demonstration programs included in the distribution.


ABCL is a totally different beast because it’s a Java implementation, so there’s no real notion of standalone executable. In order to be able to use a clonified program portably with ABCL, the dump macro does as in ECL: it simply expands to a call to the specified function.

There’s more to it than that though. It is possible to get closer to standalone executables with ABCL by providing your whole application in a jar file, and overriding ABCL’s entry point with a custom interpreter running the main function automatically. I have described this process in more details in the following blog entry: http://www.didierverna.com/sciblog/index.php?post/2011/01/22/Towards-ABCL-Standalone-Executables.

Clon helps you to do this to some extend. If the :dump configuration option is set (see Configuration), then the dump macro doesn’t do as described above, but instead dumps a Java file containing an alternate ABCL interpreter that you can compile and add to the original ABCL jar file, along with the Lisp file containing the main function. If you want more details on this, you will need to look at the Makefile in the demo/ directory and also at the file make/config.make. You can also use make -n clon-dump LISP=ABCL to see it in (fake) action.

The file in question is created based on a template that is located under etc/abcl/template.java in the distribution, so you can also edit this file, copy it, or do whatever you want with it. Note that this file is not installed anywhere. Every time dumping is requested, Clon looks for it in its own directory tree, so it must stay there.

Also, if you ever want to modify its contents and keep it as a template for dumping (for example, in order to use ‘ql:quickload’ instead of ‘asdf:load-system’, you should know that this file is read in as a Lisp format string, and in must always contain three format directives: the first one for the class name, the second one for the program invocation name (argv[0]), and the thrid one for the file containing the call to dump. Again, better take a look at how it is done in the demonstration programs.


Everything should work normally in Lispworks, but please remember that dumping a complete application is only possible in the Professional or Enterprise editions.


Finally, dumping a complete application with Allegro is complicated, but more importantly only possible in the Enterprise edition. Because of that, Clon’s dumping facility is currently limited to the dumplisp feature, which only dumps a Lisp image. When dumped with ACL, the demonstration programs included in the distribution also get their own shell wrappers for loading the concerned images.