Foreign modules may be linked to Prolog in two ways. Using
static linking, the extensions, a (short) file defining main()
which attaches the extensions calls Prolog and the SWI-Prolog kernel
distributed as a C-library are linked together to form a new executable.
Using dynamic linking, the extensions are linked to a shared
library (.so file on most Unix systems) or dynamic-link
library (.DLL file on Microsoft platforms) and loaded into
the the running Prolog process.71The
system also contains code to load .o files directly for
some operating systems, notably Unix systems using the BSD a.out
executable format. As the number of Unix platforms supporting this gets
quickly smaller and this interface is difficult to port and slow, it is
no longer described in this manual. The best alternatively would be to
use the dld package on machines do not have
shared libraries.
The static linking schema can be used on all versions of
SWI-Prolog. Whether or not dynamic linking is supported can be deduced
from the prolog-flag open_shared_object (see
current_prolog_flag/2).
If this prolog-flag yields true,
open_shared_object/2
and related predicates are defined. See
section 9.4 for a suitable high-level
interface to these predicates.
All described approaches have their advantages and disadvantages. Static linking is portable and allows for debugging on all platforms. It is relatively cumbersome and the libraries you need to pass to the linker may vary from system to system, though the utility program plld described in section 9.7 often hides these problems from the user.
Loading shared objects (DLL files on Windows) provides sharing and protection and is generally the best choice. If a saved-state is created using qsave_program/[1,2], an initialization/1 directive may be used to load the appropriate library at startup.
Note that the definition of the foreign predicates is the same, regardless of the linking type used.