Next: Foreign Function Calls, Previous: Foreign Data Structure Examples, Up: Foreign Function Interface
Foreign object files can be loaded into the running Lisp process by
calling load-shared-object
.
Load a shared library / dynamic shared object file / similar foreign container specified by designated
pathname
, such as a .so on anelf
platform.Locating the shared object follows standard rules of the platform, consult the manual page for dlopen(3) for details. Typically paths speficied by environment variables such as LD_LIBRARY_PATH are searched if the
pathname
has no directory, but on some systems (eg. Macos
X) search may happen even ifpathname
is absolute. (On Windows LoadLibrary is used instead of dlopen(3).)On non-Windows platoforms calling
load-shared-object
again with anpathname
equal
to the designated pathname of a previous call will replace the old definitions; if a symbol was previously referenced thru the object and is not present in the reloaded version an error will be signalled. Reloading may not work as expected if user or library-code has called dlopen(3) on the same shared object.
load-shared-object
interacts withsb-ext:save-lisp-and-die:
1. If
dont-save
is true (default is NIL), the shared object will be dropped whensave-lisp-and-die
is called--
otherwise shared objects are reloaded automatically when a saved core starts up. Specifyingdont-save
can be useful when the location of the shared object on startup is uncertain.2. On most platforms references in compiled code to foreign symbols in shared objects (such as those generated by DEFINE-ALIEN-ROUTINE) remain valid across
save-lisp-and-die
. On those platforms where this is not supported, awarning
will be signalled when the core is saved--
this is orthogonal fromdont-save
.