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 anelfplatform.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
pathnamehas no directory, but on some systems (eg. MacosX) search may happen even ifpathnameis absolute. (On Windows LoadLibrary is used instead of dlopen(3).)On non-Windows platoforms calling
load-shared-objectagain with anpathnameequalto 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-objectinteracts withsb-ext:save-lisp-and-die:1. If
dont-saveis true (default is NIL), the shared object will be dropped whensave-lisp-and-dieis called--otherwise shared objects are reloaded automatically when a saved core starts up. Specifyingdont-savecan 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, awarningwill be signalled when the core is saved--this is orthogonal fromdont-save.