dlclose(3c)
dlclose - Closes a shared object
As shipped in IRIX 6.5.19. 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)