Foreign Code

Prolog QOF files do not contain any foreign code or foreign data structures. As discussed in the previous section, this is different from saved-states in previous releases of Quintus Prolog.

However, QOF files can have dependencies on object files that will be automatically loaded when the QOF file is loaded. These dependencies can arise because:

  1. The QOF file was compiled with the stand-alone compiler qpc (see sap-srs-qpc) and its source file contained calls to load_foreign_files/2, which will have been turned into object file dependencies in the QOF file.
  2. The QOF file was saved from a Prolog session, using save_program/[1,2] or save_modules/2, in which foreign code had been previously loaded. The object files loaded will be recorded as object file dependencies in the QOF file.

The qnm utility can be used (from the command prompt) to see the list of dependencies in a QOF file:

     % qnm -D file.qof

It is slower to start up a QOF file with object file dependencies because the object files must be re-linked and re-loaded. This re-linking and re-loading will occur every time the QOF file is loaded and the necessary object files are not yet loaded into the system. If this start-up time becomes a problem then this can be tackled by statically linking your foreign code into the Prolog system. This is described in sap-srs. This will make the foreign code become part of the Prolog executable so there is no run-time linking required at all. In addition, on most systems, this Prolog code will now be demand-paged from the executable, which will improve start-up time and reduce paging (as compared with dynamic linking). We recommend switching over to using static linking for programs with a lot of foreign code. The dynamic foreign language interface can be used for loading code while testing, but once your foreign code is stable it is better to have it statically linked. Furthermore, dynamically loaded foreign code cannot be debugged with a debugger such as gdb(1), so you will also need to statically link the foreign code so that the debugger can be used on the resulting executable. This contradicts the fact that foreign code should be dynamically loaded while testing.

All foreign code is either linked into the Prolog executable, or is re-loaded when a QOF file is loaded. This means that when a program is started the foreign code will always be in an uninitialized state. This is exactly the same as any other program. However, this is a change from saved-states in previous releases of Quintus Prolog that saved the initialized foreign state. The new semantics is much cleaner, is consistent with standard practice, and avoids previous problems with invalid initializations that were not valid in the new process. This latter problem was particularly problematic for libraries (such as Curses, X Windows, and database interfaces) since the user did not usually have source code for the libraries and how they initialized and what they depended upon could not be easily understood. In Quintus Prolog Release 3, foreign code linked with Prolog, or loaded into Prolog, will work just the same as if it were a separate program independent of Prolog.

It is possible that some of your previous programs relied on the saving of foreign state into saved-states. If you have such programs then they will need to be changed. Usually the change will involve making sure that the foreign code is explicitly initialized each time the application is run. The initialization facilities described below, see ref-sls-igs, may be useful for this.