Loading Shared Object Files - SBCL 1.0.31 User Manual
Description: SBCL 1.0.31 User Manual

Next: Foreign Function Calls, Previous: Foreign Data Structure Examples, Up: Foreign Function Interface

### 8.6 Loading Shared Object Files

Foreign object files can be loaded into the running Lisp process by calling `load-shared-object`.

— Function: sb-alien:load-shared-object pathname &key dont-save

> Load a shared library / dynamic shared object file / similar foreign container specified by designated `pathname`, such as a .so on an `elf` 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. Mac `os` X) search may happen even if `pathname` is absolute. (On Windows LoadLibrary is used instead of dlopen(3).)

> On non-Windows platoforms calling `load-shared-object` again with an `pathname` `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 with `sb-ext:save-lisp-and-die:`

> 1. If `dont-save` is true (default is NIL), the shared object will be dropped when `save-lisp-and-die` is called `--` otherwise shared objects are reloaded automatically when a saved core starts up. Specifying `dont-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, a `warning` will be signalled when the core is saved `--` this is orthogonal from `dont-save`.