Node:The Application Builder, Next:User-defined Main Programs, Previous:Runtime Systems on Target Machines, Up:Stand-alone Executables
spld
under UNIX
The application builder, spld
, is used for creating
stand-alone executables. This tool replaces the tools
spmkrs
and spmkds
of previous versions of SICStus. It is
invoked as:
% spld [ Option | InputFile ] ...
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:
--help
-v
--verbose
-vv
--verbose
, and
switches on verbose flags (if possible) to the compiler and linker.
--version
spld
and exits successfully.
-o
--output=filename
a.out
on UNIX systems).
-E
--extended-rt
-D
--development
--main=prolog
.
--main=type
runtime_entry(+Message) hook
user:runtime_entry(+Message)
prolog
, user
, restore
and load
.
prolog
-D
. The executable will start the Prolog top-level.
This is the default if -D
is specified and no
.sav
, .pl
, .po
, or .ql
files are specified.
user
user_main()
.
This option is not compatible with -D
. See User-defined Main Programs.
restore
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
.
load
.pl
, .po
or
.ql
. This is the default if there are .pl
, .po
or
.ql
but no .sav
files among Files. 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
. Note that this is almost like
--main==restore
except that no saved-state will be
restored before loading the other files.
none
-D
.
--window
--main=user
is specified, 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.
--moveable
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 Environment Variables) 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.
-S
--static
--static
is specified, a static version of the SICStus run-time
will be used and any SICStus foreign resources specified with
--resources
will be statically linked with the executable. In
addition, --static
implies --embed-rt-sav
,
--embed-sav-file
and --resources-from-sav
.
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.
--shared
--static
. Implies
--main=none
.
Not supported on all platforms.
--resources=ResourceList
tcltk
, or they can be complete paths to a foreign resource
(with or without extensions). Example
% spld [...] --resources=tcltk,clpfd,/home/joe/foobar.soThis 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.
--resources-from-sav
--no-resources-from-sav
--resources
or --embed-sav-file
), this option extracts information from the
embedded saved-state about the names of the foreign
resources that were loaded when the saved-state was created. This
is the default for static executables when no other resource is
specified except the embedded saved-state. This option is only
supported when a saved-state is embedded as a data
resource. See All-in-one Executables, for more information.
Use --no-resources-from-sav
to ensure that this feature is
not enabled.
--respath=Path
spld
will always search the default library directory as
a last resort, so if this option is not specified, only the default
resources will be found. See also the --resources
option above.
--config=ConfigFile
--cflag=CFlag
-LD
--cflag
.
--sicstus=Executable
spld
relies on using SICStus during some stages of its
execution. The default is the SICStus-executable installed with the
distribution. Executable can be used to override this, in case
the user wants to use another SICStus executable.
--interactive
-i
--main=load
or --main=restore
. Calls
SP_force_interactive()
(see Initializing the Prolog Engine)
before initializing SICStus.
--memhook=hook obsolescent
--more-memory
--no-more-memory
--shared
. Somewhat experimental
since the required linker options are not well documented. This is the
default on Linux. It can be forced on (off) by specifying
--more-memory
(--no-more-memory
).
--lang=Dialect
prolog_flag(language,_,Dialect)
.
Dialect can be one of iso
or sicstus
. The language
mode is set before restoring or loading any argument files.
This option can only be used with --main=load
and
--main=restore
.
--userhook
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.
SU_initialize()
should be defined as:
int SU_initialize(int argc, char *argv[])The contents of
argv
should not be modified.
SU_initialize()
should return 0 for success and non-zero for
failure. If a non-zero value is returned, the development system
exits with the return value as error code.
--with_jdk=DIR
--with_tcltk=DIR
--with_tcl=DIR
--with_tk=DIR
--with_bdb=DIR
--keep
--nocompile
--keep
.
--namebase=namebase
spldgen_
or, if --static
is specified, spldgen_s_
.
--embed-rt-sav
--no-embed-rt-sav
--embed-rt-sav
will embed the SICStus run-time .sav
file
into the executable. This is off by default unless --static
is
specified. It can be forced on (off) by specifying --embed-rt-sav
(--no-embed-rt-sav
).
--embed-sav-file
--no-embed-sav-file
--embed-sav-file
will embed any .sav
file passed to
spld
into the executable. This is just a shorthand for
avoiding the ugly data resource syntax of the --resources
option. This is the default when --static
is specified.
It can be forced on (off) by specifying --embed-sav-file
(--no-embed-sav-file
). A file ./foo/bar.sav
will be added
with the data resource name /bar.sav
, i.e. as if
--resources=./foo/bar.sav=/bar.sav
had been specified.
--multi-sp-aware
--static
or
pre-linked foreign resources. See Multiple SICStus Run-Times in C, for details.
Arguments to spld
not recognized as options are assumed
to be input-files and are handled as follows:
*.pl
*.po
*.ql
SP_load()
at run-time (if --main
is
load
or restore
.
If the intention is to make an executable that works independently of
the run-time working directory, avoid relative file names. Use absolute
file names instead, SP_APP_DIR
, SP_LIBRARY_DIR
, or embed a
.sav
file as a data resource, using --resource
.
*.sav
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.
*.so
*.sl
*.s.o
*.o
*.obj
*.dll
*.lib
*.dylib
*.c
*.cc
*.C
*.cpp
*.c++
If an argument is still not recognized, it will be passed unmodified to the linker.