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:
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.
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.