Loading C Code with Chapters

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.
John Chambers<jmc@research.bell-labs.com>
Last modified: Wed Nov 11 11:09:58 EST 1998