dyn.load {base} | R Documentation

## Foreign Function Interface

### Description

Load or unload DLLs (also known as shared objects), and test whether a C function or Fortran subroutine is available.

### Usage

    dyn.load(x, local = TRUE, now = TRUE, ...)
    dyn.unload(x)

    is.loaded(symbol, PACKAGE = "", type = "")

### Arguments

`x` | a character string giving the pathname to a DLL, also known as a dynamic shared object. (See ‘Details’ for what these terms mean.)
`local` | a logical value controlling whether the symbols in the DLL are stored in their own local table and not shared across DLLs, or added to the global symbol table. Whether this has any effect is system-dependent. It is ignored on Windows.
`now` | a logical controlling whether all symbols are resolved (and relocated) immediately the library is loaded or deferred until they are used. This control is useful for developers testing whether a library is complete and has all the necessary symbols, and for users to ignore missing symbols. Whether this has any effect is system-dependent. It is ignored on Windows.
`...` | other arguments for future expansion. See section ‘Windows’ below.
`symbol` | a character string giving a symbol name.
`PACKAGE` | if supplied, confine the search for the `name` to the DLL given by this argument (plus the conventional extension, ‘.so’, ‘.sl’, ‘.dll’, ...). This is intended to add safety for packages, which can ensure by using this argument that no other package can override their external symbols. This is used in the same way as in `.C`, `.Call`, `.Fortran` and `.External` functions.
`type` | The type of symbol to look for: can be any (`""`, the default), `"Fortran"`, `"Call"` or `"External"`.

### Details

The objects `dyn.load` loads are called ‘dynamically loadable libraries’ (abbreviated to ‘DLL’) on all platforms except macOS, which uses the term for a different sort of object. On Unix-alikes they are also called ‘dynamic shared objects’ (‘DSO’), or ‘shared objects’ for short. (The POSIX standards use ‘executable object file’, but no one else does.)

See ‘See Also’ and the ‘Writing R Extensions’ and ‘R Installation and Administration’ manuals for how to create and install a suitable DLL.

Unfortunately a very few platforms (e.g., Compaq Tru64) do not handle the `PACKAGE` argument correctly, and may incorrectly find symbols linked into R.

The additional arguments to `dyn.load` mirror the different aspects of the mode argument to the `dlopen()` routine on POSIX systems. They are available so that users can exercise greater control over the loading process for an individual library. In general, the default values are appropriate and you should override them only if there is good reason and you understand the implications.

External code must not change the floating point control word, but many DLLs do so. Common changes are to set it to use 53 bit precision instead of R's default 64 bit precision, or to unmask some exceptions. `dyn.load` detects such changes, and restores R's control word to its default value of hex 8001F. This may cause the DLL to malfunction; if so, it should be rewritten to save and restore the control word itself. If `warn.FPU` is set to `TRUE` using the `options` function, a warning will be printed. (If the warning says that the control word was changed from some other value than 8001F, please report the circumstances to the Windows maintainers: that probably indicates an internal bug.)

### Value

The function `dyn.load` is used for its side effect which links the specified DLL to the executing R image. Calls to `.C`, `.Call`, `.Fortran` and `.External` can then be used to execute compiled C functions or Fortran subroutines contained in the library. The return value of `dyn.load` is an object of class `DLLInfo`. See `getLoadedDLLs` for information about this class.

The function `dyn.unload` unlinks the DLL. Note that unloading a DLL and then re-loading a DLL of the same name may or may not work: on Solaris it uses the first version loaded.

`is.loaded` checks if the symbol name is loaded and searchable and hence available for use as a character string value for argument `.NAME` in `.C` or `.Fortran` or `.Call` or `.External`. It will succeed if any one of the four calling functions would succeed in using the entry point unless `type` is specified. (See `.Fortran` for how Fortran symbols are mapped.) Note that symbols in base packages are not searchable, and other packages can be so marked.

### Windows

The ‘standard mechanisms for loading DLLs’ include a search order for where a DLL is found (if not given as an absolute path, which is preferred), and of where its dependent DLLs will be found. This search path depends on the version of Windows and its security settings, but for versions since Windows XP SP1 it is

- The directory from which the application was launched.

- The various system directories, e.g. ‘c:/Windows/system32’, ‘c:/Windows/system’ and ‘c:/Windows’.

- The current directory.

- Along the search path for executables given by the environment variable PATH.

Packages often want to supply dependent DLLs in their ‘libs’ directory, and do this by setting the PATH variable (`library.dynam` does that automatically in recent versions of R), but the DLL search order means that DLLs in the launch directory and in system directories will be preferred. On Windows XP SP1 and later there is a way to modify the search order. If argument `DLLpath` is supplied to `dyn.load`, the latter makes use of the Windows system call `SetDllDirectory` to insert the value of `DLLpath` in second place, and removes the current directory, for the duration of that `dyn.load` call. (Note that only one directory can be inserted in this way.)

Users have been confused by messages like

     error: unable to load shared object
     '.../library/rJava/libs/x64/rJava.dll':
     LoadLibrary failure:  The specified module could not be found.

The final line is a Windows (not R) diagnostic: the ‘module’ that could not be found is not ‘rJava.dll’ but something else Windows is looking for (here most likely Java DLLs): if you are lucky there will be a dialog box with more details.

### Warning

Do not use `dyn.unload` on a DLL loaded by `library.dynam`: use `library.dynam.unload`. This is needed for system housekeeping.

### Note

`is.loaded` requires the name you would give to `.C` etc and not (as in S) that remapped by the defunct functions `symbol.C` or `symbol.For`.

The creation of DLLs and the runtime linking of them into executing programs is very platform dependent. In recent years there has been some simplification in the process because the C subroutine call `dlopen` has become the POSIX standard for doing this. Under Unix-alikes `dyn.load` uses the `dlopen` mechanism and should work on all platforms which support it. On Windows it uses the standard mechanism (`LoadLibrary`) for loading DLLs.

The original code for loading DLLs in Unix-alikes was provided by Heiner Schwarte.

### References

Becker, R. A., Chambers, J. M. and Wilks, A. R. (1988) The New S Language. Wadsworth & Brooks/Cole.

### See Also

`library.dynam` to be used inside a package's `.onLoad` initialization.

`SHLIB` for how to create suitable DLLs.

`.C`, `.Fortran`, `.External`, `.Call`.

### Examples

    ## expect all of these to be false in R >= 3.0.0.
    is.loaded("supsmu") # Fortran entry point in stats
    is.loaded("supsmu", "stats", "Fortran")
    is.loaded("PDF", type = "External") # pdf() device in grDevices

[Package base version 3.3.2 Index]