dll-exports is implemented only on Windows, Linux, x86/x64 Solaris, Macintosh and FreeBSD. It controls whether the image saved is an executable or a dynamic library (DLL), just as for save-image.
If dll-exports is :default, the delivered image is an executable. The value :com is supported on Microsoft Windows only (see below). Otherwise dll-exports should be list (potentially nil). In this case a dynamic library is saved, and each string in dll-exports names a function which becomes an export of the dynamic library and should be defined as a Lisp function using fli:define-foreign-callable. Each exported name can be found by GetProcAddress (on Windows) or dlsym (on other platforms). The exported symbol is actually a stub which ensures that the LispWorks dynamic library has finished initializing, and then enters the Lisp code.
On Microsoft Windows dll-exports can also contain the keyword :com, or dll-exports can simply be the keyword :com, both of which mean that the DLL is intended to be used as a COM server. See the
LispWorks COM/Automation User Guide and Reference Manual
for details.
To deliver a dynamic library on non-Windows platforms, the build machine must have a C compiler installed. This is typically gcc (which is available on the Macintosh by installing Xcode).
On Mac OS X the default behavior is to generate an object of type "Mach-O dynamically linked shared library" with file type dylib. See image-type below for information about creating another type of library on Mac OS X.
On Microsoft Windows you can use LoadLibrary from the main application to load the DLL and GetProcAddress to find the address of the external names.
There is an example DLL delivery script in Delivering a dynamic library.
For more information about the behavior of LispWorks DLLs (dynamic libraries) see the chapter "LispWorks as a dynamic library" in the LispWorks User Guide and Reference Manual .
LispWorks Delivery User Guide - 10 Aug 2017