When an S chapter includes some compiled C (or Fortran or C++) code, the object file (the "shared object file" to be precise) is automatically linked into S, making the global routines available through the appropriate S interface function. Chaper 11 and, in particular section 11.1.3, describes the essential ideas. Here are a few subtleties, however, that may present problems.
The most likely problems occur when the routines in the chapter rely
on other routines, from one or more object-code libraries.
The operating system command that creates the shared object file does
not, generally, resolve the references when the S.so
file
is created.
Instead, a run-time loader resolves the references when it is called,
automatically, by the S evaluator manager at the time the chapter is
attached.
The loader needs to be told where to search for object files and
libraries;
the shell variable LD_LIBRARY_PATH
specifies this in the
usual shell convention for search paths (on Unix and Linux, a
colon-separated list of directory names).
On some systems, at least, it is essential that this shell
variable be set before starting the S process.
The value is stored at process initialization time and used for all
dynamic linking.
The S shell script itself (as long as you are using the one for
the current version of S) itself appends the directory for S-specific
object code just before starting the S process.
Any other directories you need to search should be included in the
path before that.
So, for example, if you want to search
"/usr/local/src/Java/lib"
when linking in any object
files, and you are using something like the original Unix shell:
$ LD_LIBRARY_PATH="/usr/local/src/Java/lib:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH
If the routines to be found are in shared-object libraries, you also
need to indicate the need for those in creating S.so
, by
setting the LOCAL_LIBS
variable, as shown on page 411.