% spld [ Option | InputFile ] ...
The application builder, spld, is used for creating stand-alone executables.
spld takes the files specified on the command line and combines them into an executable file, much like the UNIX ld or the Windows link commands.
Note that no pathnames passed to spld should contain spaces. Under Windows, this can be avoided by using the short version of pathnames as necessary.
The input to spld can be divided into Options and Files, which can be arbitrarily mixed on the command line. Anything not interpreted as an option will be interpreted as an input file. Do not use spaces in any file or option passed to spld. Under Windows you can use the short file name for files with space in their name. The following options are available:
prologuseruser_main().
This option is not compatible with -D. See User-defined Main Programs.
restoresave_program/[1,2]. This is the default if a `.sav' file is
found among Files. It is only meaningful to specify one
`.sav' file. If it was created by save_program/2, the given
startup goal is run. Then the executable will any Prolog code
specified on the command line. Finally, the goal
user:runtime_entry(start) is run. The executable exits with 0
upon normal temination and with 1 on failure or exception. Not
compatible with -D.
loaduser:runtime_entry(start) is run. The executable
exits with 0 upon normal temination and with 1 on failure or exception.
Not compatible with -D. Note that this is almost like
--main==restore except that no saved-state will be
restored before loading the other files.
noneuser_main() should not set the
user-stream hooks. C/C++ source code files specified on the
command-line will be compiled with -DSP_WIN=1 if this option is
given.
Under UNIX, paths are normally hardcoded into executables in order for them to find the SICStus libraries and bootfiles. Two paths are normally hardcoded; the value of SP_PATH and, where possible, the runtime library search path using the -R linker option (or equivalent). If the linker does not support the -R option (or an equivalent), a wrapper script is generated instead, which sets LD_LIBRARY_PATH (or equivalent).
The --moveable option turns off this behavior, so the executable is not dependent on SICStus being installed in a specific place. On some platforms the executable can figure out where it is located and so can locate any files it need, e.g. using SP_APP_DIR and SP_RT_DIR. On some UNIX platforms, however, this is not possible. In these cases, if this option is given, the executable will rely on environment variables (SP_PATH (see too-sicstus) and LD_LIBRARY_PATH, etc.) to find all relevant files.
Under Windows, this option is always on, since Windows applications do
not need to hardcode paths in order for them to find out where they're
installed. See Runtime Systems on Windows Target Machines, for more
information on how SICStus locates its libraries and bootfiles.
Even with --static, spld will go with the linker's default, which is usually dynamic. If you are in a situation where you would want spld to use a static library instead of a dynamic one, you will have to hack into spld's configuration file spconfig-version (normally located in <installdir>/bin). We recommend that you make a copy of the configuration file and specify the new configuration file using --config=<file>. A typical modification of the configuration file for this purpose may look like:
[...]
TCLLIB=-Bstatic -L/usr/local/lib -ltk8.0 -ltcl8.0 -Bdynamic
[...]
Use the new configuration file by typing
% spld [...] -S --config=/home/joe/hacked_spldconfig [...]
The SICStus run-time depends on certain OS support that is only available
in dynamically linked executables. For this reason it will probably not
work to try to tell the linker to build a completely static executable,
i.e. an executable that links statically also with the C library and
that cannot load shared objects.
Not supported on all platforms.
tcltk, or they can be complete paths to a foreign resource
(with or without extensions). Example
% spld [...] --resources=tcltk,clpfd,/home/joe/foobar.so
This will cause library(tcltk), library(clpfd), and
/home/joe/foobar.so to be pre-linked with the executable. See
also the option --respath below.
It is also possible to embed a data resource, that is, the contents of an arbitrary data file that can be accessed at run-time.
It is possible to embed any kind of data, but, currently, only
restore/1 knows about data resources. For this reason it only
makes sense to embed `.sav' files.
The primary reason to embed files within the executable is to create an
all-in-one executable, that is, an executable file that does not depend
on any other files and that therefore is easy to run on machines without
SICStus installed. See All-in-one Executables, for more information.
Use --no-resources-from-sav to ensure that this feature is
not enabled.
SP_force_interactive() (see Initializing the Prolog Engine)
before initializing SICStus.
SU_initialize() function. SU_initialize() is called by the
main program before SP_initialize(). Its purpose is to call
interface functions, which must be called before SP_initialize(),
such as SP_set_memalloc_hooks(). It is not meaningful to specify
this option if --main=user or --main=none is given.
spldgen_ or, if --static is specified, spldgen_s_.
--resources=./foo/bar.sav=/bar.sav had been specified.
Arguments to spld not recognized as options are assumed to be input-files and are handled as follows:
SP_load() at run-time (if --main is
load or restore.
Please note:
If the intention is to make an executable that works independently of
the working directory at run time, avoid relative file names, for they
will be resolved at run time, not at spld time.
Use absolute
file names instead, SP_APP_DIR, SP_LIBRARY_DIR, or embed a
`.sav' file as a data resource, using --resource.
SP_restore() at run-time if
--main=restore is specified, subject to the above caveat about
relative file names.
It is not meaningful to give more than one `.sav' argument.
If an argument is still not recognized, it will be passed unmodified to the linker.