dlclose(3c)

dlclose - Closes a shared object

Showing IRIX 6.5.30 (default release). Last changed in IRIX 6.5.19.

NAME
     dlclose - Closes a shared object

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

     #include <dlfcn.h>

     int dlclose(void *handle);

DESCRIPTION
     dlclose disassociates from the current process a shared object
     previously opened by the dlopen, sgidladd, or sgidlopen_version
     command.  Once an object is closed by 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
     are also closed (however no object still open as a result of any
     dlopen, sgidladd, or sgidlopen_version command is closed until dlclose
     has closed the last open handle.

     handle is the value returned by a previous invocation of dlopen.

RETURN VALUES
     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 can also be
     loaded by another invocation of dlopen.  The same object can 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 Dynamic Shared Object (DSO) can cause 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 might 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 the rld program).  When
     multiple sgidladd commands are executed and an earlier DSO is closed
     by dlclose, this can change the symbol to which a call is resolved and
     even result in unintentional calls to different routines (with the
     same name) from a single place in the program at different times.  For
     more information, see the "Namespace Issues" section in the dlopen(3)
     man page.

SEE ALSO
     dlerror(3), dlopen(3), sgidlopen_version(3), sgidladd(3), dlsym(3)
     dso(5)