dlclose(3C)

NAME
     dlclose - close a shared object

SYNOPSIS
     cc [flag ...] file ...  -lc [library ...]

     #include <dlfcn.h>

     int dlclose(void *handle);

DESCRIPTION
     dlclose 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 ALSO
     dlerror(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.
     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".