Load or unload DLLs (also known as shared objects), and test whether a C function or Fortran subroutine is available.
dyn.load(x, local = TRUE, now = TRUE, ...) dyn.unload(x) is.loaded(symbol, PACKAGE = "", type = "")
- a character string giving the pathname to a DLL, also known as a dynamic shared object. (See ‘Details’ for what these terms mean.)
- 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.
- 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.
- a character string giving a symbol name.
- if supplied, confine the search for the
nameto 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
- The type of symbol to look for: can be any (
"", the default),
dyn.load loads are called ‘dynamically loadable libraries’ (abbreviated to ‘DLL’) on all platforms except Mac OS X, which unfortunately uses the term for a different sort of sobject. 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.
dyn.load is used for its side effect which links the specified DLL to the executing R image. Calls to
.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
getLoadedDLLs for information about this class.
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 hence available for use in
.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.)
Becker, R. A., Chambers, J. M. and Wilks, A. R. (1988) The New S Language. Wadsworth & Brooks/Cole.
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.
SHLIB for how to create suitable DLLs.
Documentation reproduced from R 2.15.3. License: GPL-2.