Function: SB-ALIEN:LOAD-SHARED-OBJECT¶
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 specified 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 platforms calling LOAD-SHARED-OBJECT again with a PATHNAME EQUAL to the designated pathname of a previous call will replace the old definitions; if a symbol was previously referenced through 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:
- 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.
- 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.
Lambda list¶
(pathname &key sb-alien::dont-save)