5.2 Linking Foreign Modules

Foreign modules may be linked to Prolog in three ways. Using static linking, the extensions, a small description file and the basic SWI-Prolog object file 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. (27).

5.2.1 What linking is provided?

The static linking schema can be used on all versions of SWI-Prolog. The feature/2 predicate may be used to find out what other linking methods are provided for this version.

• feature(open_shared_object, true)
  If this succeeds the system provides the open_shared_object/2 and related predicates that allow for handling Unix shared object files based on the Unix library functions dlopen(2) and friends. See section 5.4.
• feature(dll, true)
  If this succeeds the system provides an interface for loading .DLL files by means of open_dll/2 and friends. See section 5.4.

If either the feature open_shared_object or dll is true, the library library(shlib) provides a common interface for loading foreign files from Prolog.

5.2.2 What kind of loading should I be using?

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.

Loading shared objects or DLL files provides sharing and protection and is generally the best choice. The old (and also badly portable) save/[1,2] and save_program/[1,2] do not cooperate with this mechanism, but the more recent qsave_program/[1,2] can be used to created programs that load the appropriate library at startup.

Note that the definition of the foreign predicates is the same, regardless of the linking type used.