Mercurial > pub > dyncall > bindings
view R/rdyncall/man/dynfind.Rd @ 3:f5d4d5c2f750
- gemspec fix
author | cslag |
---|---|
date | Thu, 31 Dec 2015 20:24:53 +0100 |
parents | 0cfcc391201f |
children |
line wrap: on
line source
\name{dynfind} \alias{dynfind} \title{Portable searching and loading of shared libraries} \description{Function to load shared libraries using a platform-portable interface.} \usage{ dynfind(libnames, auto.unload=TRUE) } \arguments{ \item{libnames}{vector of character strings specifying several short library names.} \item{auto.unload}{logical: if \code{TRUE} then a finalizer is registered that closes the library on garbage collection. See \code{\link{.dynload}} for details.} } \details{ \code{dynfind} offers a platform-portable naming interface for loading a specific shared library. The naming scheme and standard locations of shared libraries are OS-specific. When loading a shared library dynamically at run-time across platforms via standard interfaces such as \code{\link{.dynload}} or \code{\link{dyn.load}}, a platform-test is usually needed to specify the OS-dependant library file path. This \emph{library name problem} is encountered via breaking up the library file path into several abstract components: \tabular{cccc}{ \emph{<location>} \tab \emph{<prefix>} \tab \emph{<libname>} \tab \emph{<suffix>} \cr } By permutation of values in each component and concatenation, a list of possible file paths can be derived. \code{dynfind} goes through this list to try opening a library. On the first success, the search is stopped and the function returns. Given that the three components \sQuote{location}, \sQuote{prefix} and \sQuote{suffix} are set up properly on a per OS basis, the unique identification of a library is given by \sQuote{libname} - the short library name. For some libraries, multiple \sQuote{short library name} are needed to make this mechanism work across all major platforms. For example, to load the Standard C Library across major R platforms: \preformatted{ lib <- dynfind(c("msvcrt","c","c.so.6")) } On Windows \code{MSVCRT.dll} would be loaded; \code{libc.dylib} on Mac OS X; \code{libc.so.6} on Linux and \code{libc.so} on BSD. Here is a sample list of values for the three other components: \itemize{ \item \sQuote{location}: \dQuote{/usr/local/lib/}, \dQuote{/Windows/System32/}. \item \sQuote{prefix}: \dQuote{lib} (common), \dQuote{} (empty - common on Windows). \item \sQuote{suffix}: \dQuote{.dll} (Windows), \dQuote{.so} (ELF), \dQuote{.dylib} (Mac OS X) and \dQuote{} (empty - useful for all platforms). } The vector of \sQuote{locations} is initialized by environment variables such as '\code{PATH}' on Windows and \code{LD_LIBRARY_PATH} on Unix-flavour systems in additional to some hardcoded locations: \file{/opt/local/lib}, \file{/usr/local/lib}, \file{/usr/lib} and \file{/lib}. (The set of hardcoded locations might expand and change within the next minor releases). The file extension depends on the OS: '\code{.dll}' (Windows), '\code{.dylib}' (Mac OS X), '\code{.so}' (all others). On Mac OS X, the search for a library includes the \sQuote{Frameworks} folders as well. This happens before the normal library search procedure and uses a slightly different naming pattern in a separate search phase: \tabular{c}{ \emph{<frameworksLocation>} \bold{Frameworks/} \emph{<libname>} \bold{.framework/} \emph{<libname>} } The \sQuote{frameworksLocation} is a vector of locations such as \code{/System/Library/} and \code{/Library/}. \code{dynfind} loads a library via \code{\link{.dynload}} passing over the parameter \code{auto.unload}. } \value{ \code{dynfind} returns an external pointer (library handle), if search was successful. Otherwise, if no library is located, a \code{NULL} is returned. } \seealso{ See \code{\link{.dynload}} for details on the loader interface to the OS-specific dynamic linker. } \keyword{programming} \keyword{interface}