DLCLOSE(3C)DLCLOSE(3C)NAMEdlclose - close a shared object
SYNOPSIS
cc [flag ...] file ... -lc [library ...]
#include <dlfcn.h>
int dlclose(void *handle);
DESCRIPTIONdlclose disassociates a shared object previously opened by dlopen,
sgidladd, or sgidlopen_version from the current process. Once an object
has been closed using dlclose, its symbols are no longer available to
dlsym or to the program. All objects loaded automatically as a result of
invoking dlopen, on the referenced object [see dlopen(3) sgidladd, or
sgidlopen_version] are also closed (however no object still open via any
dlopen, sgidladd, or sgidlopen_version is closed till the last open
handle is dlclosed).
handle is the value returned by a previous invocation of dlopen.
SEE ALSOdlerror(3), dlopen(3), sgidlopen_version(3), sgidladd(3), dlsym(3),
dso(5).
DIAGNOSTICS
If the referenced object was successfully closed, dlclose returns 0. If
the object could not be closed, or if handle does not refer to an open
object, dlclose returns a non-0 value. More detailed diagnostic
information is available through dlerror.
NOTES
A successful invocation of dlclose does not guarantee that the objects
associated with handle are actually removed from the address space of the
process. Objects loaded by one invocation of dlopen may also be loaded
by another invocation of dlopen. The same object may also be opened
multiple times. An object is not removed from the address space until
all references to that object through an explicit dlopen invocation have
been closed and all other objects implicitly referencing that object have
also been closed.
Once an object has been closed by dlclose, referencing symbols contained
in that object can cause undefined behavior.
Use of dlclose on a DSO can cause surprising side effects because dlclose
forces many symbol's GOT entries to be reset for re-lazy-evaluation. A
result of this is that previously-saved (by the program or a DSO)
function pointers may hold obsolete or incorrect values.
Page 1
DLCLOSE(3C)DLCLOSE(3C)
Symbol lookups proceed in order on a linear list, and a DSO is not opened
twice with the same version number (unless different dlopen paths make
the DSO name appear different to rld). When multiple sgidladds are done
and an earlier DSO is dlclosed this can change what symbol a call is
resolved to and even result in unintentionally calling different routines
(with the same name) from a single place in the program at different
times. See the discussion of this in the dlopen description under
"NAMESPACE ISSUES".
Page 2
