Next: too-splm, Previous: too-spld, Up: Command Reference Pages [Contents][Index]
splfr
— SICStus Prolog Foreign Resource Linker% splfr [ Option | InputFile ] …
The foreign resource linker, splfr
, is used for creating
foreign resources (see Foreign Resources). splfr
reads terms from a Prolog file, applying op declarations and
extracting any foreign_resource/2
fact with first
argument matching the resource name and all foreign/[2,3]
facts. Based on this information, it generates the necessary
glue code, and combines it with any additional C or object files
provided by the user into a linked foreign resource. The output
file name will be the resource name with a suitable extension.
The input to splfr
can be divided into Options and
InputFiles and they can be arbitrarily mixed on the command
line. Anything not interpreted as an option will be interpreted as an
input file. Exactly one of the input files should be a Prolog file.
The following options are available:
Prints out a summary of all options.
Print detailed information about each step in the compilation/linking sequence. Multiple occurrences increase verbosity.
Same as -v -v.
Prints out the version number of spld
and exits successfully.
Specify another configuration file. This option is not intended for normal use. The file name may not contain spaces.
Override values from the configuration file. Can occur multiple times. For instance, ‘--conf CC=/usr/bin/gcc’ would override the default C compiler.
CFlag is an option to pass to the C-compiler (or C++ compiler). This option can occur multiple times.
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 occurrences 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.
CXXFlag is an option to pass to the C++ compiler (in addition to any C flags specified with --cflag). This option can occur multiple times.
This enables improved handling of C++ code. It is automatically enabled if any C++ source code is detected.
On some platforms the C++ compiler will be used for linking instead of the C compiler. On some platforms you may need to pass extra options to ensure the C++ library is available.
It can be disabled with --nocxx, e.g. if the C++ support causes some backward compatibility problem.
Do not process the rest of the command line, but send it directly to the compiler/linker. Note that linking is often performed by the compiler.
splfr
relies on using SICStus during some stages of its
execution. The default is the development system installed with the
distribution. Executable can be used to override this, in case
the user wants to use another development system.
Keep temporary files and interface code and rename them to human-readable names. Not intended for the casual user, but useful if you want to know exactly what code is generated.
Specify the resource’s name. This defaults to the basename of the Prolog source file found on the command line.
Specify output file name. This defaults to the name of the resource, suffixed with the platform’s standard shared object suffix (i.e. ‘.so’ on most UNIX dialects, ‘.dll’ under Windows). The use of this option is discouraged, except to change the output directory.
Create a statically linked foreign resource instead of a
dynamically linked one, which is the default. A statically linked
foreign resource is a single object file, which can be
prelinked into a Prolog system. See also the spld
tool,
The Application Builder.
Under UNIX, the default is to embed into the shared object all linker library directories for use by the dynamic linker. For most UNIX linkers this corresponds to adding a -Rpath for each -Lpath. The --no-rpath option inhibits this.
Do Not compile, just generate code. This may be useful in Makefiles, for example to generate the header file in a separate step. Implies --keep.
namebase will be used as part of the name of generated files. The default name base is the resource name (e.g. as specified with --resource). If --static is specified, then the default namebase is the resource name followed by ‘_s’.
Specify the name of the generated header file. The default
is namebase_glue.h
.
All C files that define foreign functions or that call SICStus API
functions should include this file. Among other things the generated
header file includes prototypes corresponding to the foreign/[2,3]
declarations in the Prolog code.
Create a (dynamic) foreign resource that can be loaded by several SICStus runtimes in the same process, at the same time. See Foreign Resources and Multiple SICStus Runtimes for details.
Do Not embed paths into the foreign resource.
On platforms that support it, i.e. some versions of UNIX, the default
behavior of splfr
is to add each directory dir specified
with -Ldir to the search path used by the runtime loader
(using the SysV ld -R
option or similar). The option
--moveable turns off this behavior. For additional details, see
the corresponding option to spld
(see The Application Builder).
The Prolog source file uses library(structs)
.
This option makes splfr
understand
foreign type specifications and translate them into C declarations in
the generated header file.
See See lib-structs.
The Prolog source file uses library(objects)
.
This option makes splfr
understand
that library’s syntax extensions.
See See lib-objects.
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:
The Prolog file containing the relevant declarations. Exactly one such argument should be given.
These files are assumed to be input files to the linker and will be passed on unmodified.
These files are assumed to be C source code and will be compiled by the C-compiler before being passed to the linker.
These files are assumed to be C++ source code and will be compiled by the C++-compiler before being passed to the linker.
Prior to release 4.7, these files would be compiled with the C compiler. The --nocxx option can be used if the legacy behavior is desired.