% spld [ Option | InputFile ] ...
The application builder, spld, is used for creating stand-alone executables. See The Application Builder for an overview.
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:
user_main(). This option is not compatible with -D. See User-defined Main Programs.
save_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.
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. Note that this is almost like --main==restore except that no saved-state will be restored before loading the other files.
user_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.
Controls whether to hardcode certain paths into the executable in order for it to find the SICStus libraries and bootfiles etc.
Under UNIX, if --no-moveable is specified, paths are 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 most 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, --moveable is in effect, the executable will rely on the system properties and enviroment variables (SP_PATH (see System Properties and Environment Variables) and LD_LIBRARY_PATH etc.) to find all relevant files.
Under Windows, --moveable is always on, since Windows
applications don't need to hardcode paths in order for them to find out
where they are installed. On UNIX platforms,
--moveable is the
default (as of release 4.2) but can be turned off with
--no-moveable. See Runtime Systems on 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 runtime 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
/home/joe/foobar.so to be prelinked 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 runtime.
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
The current behavior is that if CFlag contains commas then each
comma-separated part is treated as a separate compiler option. This may
change in the future, so instead you should use multiple occurences of
--cflag. To turn off splitting at commas and treat CFlag as a
single option even it contains a comma, you can pass the option
--conf SPLIT_OPT_CFLAG=0. This can be useful with certain
options to the gcc compiler.
SP_force_interactive()(see Initializing the Prolog Engine) before initializing SICStus.
SU_initialize()is called by the main program before
SP_initialize(). Its purpose is to call interface functions that 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.
malloc. If specified as
SP_set_memalloc_hooks()will be called with
SP_SET_MEMALLOC_HOOKS_HINT_USE_MALLOCand the C library
malloc()will be used for all allocations instead of SICStus default allocator. See cpg-ref-SP_set_memalloc_hooks for more information.
Setting the process locale from the environment can suppressed by passing the --no-locale option to spld. This corresponds to the behavior prior to release 4.3.
An explicit locale that the process should set on inititialization, can be passed with the --locale option to spld.
The valid locale names depends on the operating system. Typically you
can use the locale utility, with the -a option, to
list all valid locale names.
jasper, that have special dependencies. This is mostly useful under Windows. Under UNIX, the installation script manages this automatically.
spldgen_or, if --static is specified,
--resources=./foo/bar.sav=/bar.savhad been specified.
There may be additional, undocumented, options, some of which may be described with the --help option.
Arguments to spld not recognized as options are assumed to be input-files and are handled as follows:
SP_load()at runtime (if --main is
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 runtime 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.
See The Application Builder.