dlopen(3) BSD Library Functions Manual dlopen(3)
NAME
dlopen, dlsym, dlerror, dlclose - programmatic interface to the dynamic
linker
SYNOPSIS
#include <dlfcn.h>
void *
dlopen(const char *path, int mode);
void *
dlsym(void * restrict handle, const char * restrict symbol);
const char *
dlerror(void);
int
dlclose(void *handle);
DESCRIPTION
These functions provide a simple programmatic interface to the services
of the dynamic linker. Operations are provided to add new shared objects
to a program's address space, to obtain the address bindings of symbols
defined by such objects, and to remove such objects when their use is no
longer required. All these functions use the native dyld(3),
NSModule(3), and NSObjectFileImage(3) functions to provide a compatibil-
ity library so that common unix source code may be easily compiled.
New code should use the native functions, not this compatibility layer,
see the above manual pages for usage.
dlopen() provides access to the shared object in path, returning a
descriptor that can be used for later references to the object in calls
to dlsym() and dlclose(). If path was not in the address space prior to
the call to dlopen(), it is placed in the address space. When an object
is first loaded into the address space in this way, its function _init(),
if any, is called. If path has already been placed in the address space
in a previous call to dlopen(), it is not added a second time, although a
reference count of dlopen() operations on path is maintained. A null
pointer supplied for path is interpreted as a reference to the main exe-
cutable of the process. mode controls the way in which external function
references from the loaded object are bound to their referents. It must
contain one of the following values, possibly ORed with additional flags
which will be described subsequently:
RTLD_LAZY Each external function reference is resolved when the func-
tion is first called.
RTLD_NOW All external function references are bound immediately by
dlopen().
RTLD_LAZY is normally preferred, for reasons of efficiency. However,
RTLD_NOW is useful to ensure that any undefined symbols are discovered
during the call to dlopen().
One of the following flags may be ORed into the mode argument:
RTLD_GLOBAL Symbols from this shared object and its directed acyclic
graph (DAG) of needed objects will be available for resolv-
ing undefined references from all other shared objects.
This is the only opion available for objects linked with
the -dylib flag to ld(1)
RTLD_LOCAL Symbols in this shared object and its DAG of needed objects
will be available for resolving undefined references only
from other objects in the same DAG. This is the default
for objects linked with the -bundle flag to ld(1) but it
may be set explicitly with this flag.
If dlopen() fails, it returns a null pointer, and sets an error condition
which may be interrogated with dlerror().
The dlsym() returns the address binding of the symbol described in the
null-terminated character string symbol, as it occurs in the shared
object identified by handle. The symbols exported by objects added to
the address space by dlopen() can be accessed only through calls to
dlsym(). Such symbols do not supersede any definition of those symbols
already present in the address space when the object is loaded, nor are
they available to satisfy normal dynamic linking references.
See the note about underscores and C symbols, dlsym() may or may not need
to be called with an underscore prepended to the C function name, depend-
ing upon how this package was configured.
If dlsym() is called with the special handle RTLD_NEXT, then the search
for the symbol is limited to the shared objects which were loaded after
the one issuing the call to dlsym(). Thus, if the function is called
from the main program, all the shared libraries are searched. If it is
called from a shared library, all subsequent shared libraries are
searched. RTLD_NEXT is useful for implementing wrappers around library
functions. For example, a wrapper function getpid() could access the
``real'' getpid() with dlsym(RTLD_NEXT, "getpid").
If dlsym() is called with the special handle RTLD_SELF, then the search
for the symbol is limited to the shared object issuing the call to
dlsym() and those shared objects which were loaded after it.
The dlsym() function returns a null pointer if the symbol cannot be
found, and sets an error condition which may be queried with dlerror().
The dlerror() returns a null-terminated character string describing the
last error that occurred during a call to dlopen(), dlsym(), or
dlclose(). If no such error has occurred, dlerror() returns a null
pointer. At each call to dlerror(), the error indication is reset. Thus
in the case of two calls to dlerror(), where the second call follows the
first immediately, the second call will always return a null pointer.
dlclose() deletes a reference to the shared object referenced by handle.
If the reference count drops to 0, the object is removed from the address
space, and handle is rendered invalid. Just before removing a shared
object in this way, the object's _fini() function is called, if such a
function is defined by the object. If dlclose() is successful, it
returns a value of 0. Otherwise it returns -1, and sets an error condi-
tion that can be interrogated with dlerror().
The object-intrinsic functions _init() and _fini() are called with no
arguments, and are not expected to return values.
NOTES
In darwin objects, C symbols have an underscore prepended to the symbol
name. So, the function getpid() ends up in the object file as _getpid
Most code assumes that there is no underscore and calls dlsym() with
symbol as "getpid" which would fail to find the symbol.
Depending on how the dlcompat package was built, the dlsym() function
may, or may not, automatically prepend an underscore to the passed symbol
to compensate for this. In this case calling dlsym() with symbol as
"getpid" does indeed find the _getpid symbol.
ERRORS
dlopen() and dlsym() return a null pointer in the event of errors.
dlclose() returns 0 on success, or -1 if an error occurred. Whenever an
error has been detected, a message detailing it can be retrieved via a
call to dlerror().
AUTHORS
The dlcompat package was written by Jorge Acereda <jacereda@users.source-
forge.net> and Peter O'Gorman <ogorman@users.sourceforge.net>
This man page was borrowed from FreeBSD and modified, it originally came
from Sun Microsystems, Inc.
BUGS
o None of these rountines should be expected to work as advertised with
MH_DYLIB files. They are always opened globally and may not be
closed, RTLD_NOW is ignored for them.
o The search for symbols in objects which were loaded as a result of
loading handle terminates too soon.
o None of the functions work as advertised for executables linked with
the ld(1) flag -force_flat_namespace, or when the dyld(1)
DYLD_FORCE_FLAT_NAMESPACE environment variable is set. This is
because the NSLookupSymbolInImage() function ignores the passed in
mach_header in this case.
o The underscore or not issue is unnecessarily confusing.
If you find any more, please contact Peter O'Gorman <ogor-
man@users.sourceforge.net>
SEE ALSO
ld(1) cc(1) NSModule(3) NSObjectFileImage(3) dyld(3)
BSD June 8, 2003 BSD
Mac OS X 10.3 - Generated Fri Apr 4 10:27:49 CDT 2008