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). 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 Linux/Macintosh/FreeBSD, 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 - 13 Dec 2011