DLCLOSE(3POSIX)

🫶 PROLOG 🫶

okay so before we even start, bestie, real talk: this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (so go peek at the corresponding Linux manual page for the deets on Linux behavior), or honestly the interface may not be implemented on Linux at all. 💀 not me warning you first thing.

---

✨ NAME ✨

dlclose — close a symbol table handle 💅

---

🌸 SYNOPSIS 🌸

#include <dlfcn.h>

int dlclose(void *handle);

that's it. that's the whole vibe. one function, one pointer, so much power. 👑

---

🦋 DESCRIPTION 🦋

so what does dlclose() actually do? It shall inform the system that the symbol table handle specified by handle is no longer needed by the application. bye bestie, thanks for everything. 💖

Now here's the thing — an application writer may use dlclose() to make a statement of intent on the part of the process, but this statement does not create any requirement upon the implementation. Like, you're saying "I'm done with this," but the implementation is under no obligation to act on it. The way that intent ≠ guarantee... it's giving ✨ polite suggestion ✨.

When the symbol table handle is closed, the implementation may unload the executable object files that were loaded by dlopen() when the symbol table handle was opened, and those that were loaded by dlsym() when using the symbol table handle identified by handle. May! Not shall! The audacity of "may". 🙈

Once a symbol table handle has been closed, an application should assume that any symbols (function identifiers and data object identifiers) made visible using handle are no longer available to the process. so like, don't come crawling back to them, they're gone, gone gone. 😭

Although a dlclose() operation is not required to remove any functions or data objects from the address space, neither is an implementation prohibited from doing so. The only restriction on such a removal is that no function nor data object shall be removed to which references have been relocated, until or unless all such references are removed. For instance, an executable object file that had been loaded with a dlopen() operation specifying the RTLD_GLOBAL flag might provide a target for dynamic relocations performed in the processing of other relocatable objects — in such environments, an application may assume that no relocation, once made, shall be undone or remade unless the executable object file containing the relocated object has itself been removed. 🌈 (yes that was a whole paragraph, yes it matters, no I will not be shortening it, periodt.)

---

👑 RETURN VALUE 👑

• If the referenced symbol table handle was successfully closed, dlclose() shall return 0. ✨ slay ✨
• If handle does not refer to an open symbol table handle, or if the symbol table handle could not be closed, dlclose() shall return a non-zero value. 💀

More detailed diagnostic information shall be available through dlerror(). 🩺 go ask them what went wrong, they'll tell you.

---

🎀 ERRORS 🎀

No errors are defined. literally none. the void. 🕳️

The following sections are informative. (translation: the rest of this page is vibes and context, not requirements. iykyk.)

---

💜 EXAMPLES 💜

The following example illustrates use of dlopen() and dlclose():

#include <dlfcn.h>
int eret;
void *mylib;
...
/* Open a dynamic library and then close it ... */
mylib = dlopen("mylib.so", RTLD_LOCAL | RTLD_LAZY);
...
eret = dlclose(mylib);
...

see how it's a whole little story? open the library, do your thing (the ...), close the library, and check what eret has to say about it. 🫶

---

🌟 APPLICATION USAGE 🌟

A conforming application should employ a symbol table handle returned from a dlopen() invocation only within a given scope bracketed by a dlopen() operation and the corresponding dlclose() operation. Like, stay in your lane, stay in your bracket. 🚧

Implementations are free to use reference counting or other techniques such that multiple calls to dlopen() referencing the same executable object file may return a pointer to the same data object as the symbol table handle. so you might get the same handle back twice and that's not a glitch, that's just how they do. 🔁

Implementations are also free to re-use a handle. For these reasons, the value of a handle must be treated as an opaque data type by the application, used only in calls to dlsym() and dlclose().

bestie, do NOT poke at the internals of that handle. do not dereference it. do not store stuff in it. it is a mystery box and you must respect the mystery. 🎁

---

💀 RATIONALE 💀

None.

(it's giving "no thoughts, head empty" and honestly? iconic of them.)

---

⭐ FUTURE DIRECTIONS ⭐

None.

(nothing coming down the pipeline. we stay exactly as we are. 💅)

---

🌈 SEE ALSO 🌈

• dlerror()
• dlopen()
• dlsym()

The Base Definitions volume of POSIX.1‐2017, <dlfcn.h> 📚

---

💖 COPYRIGHT 💖

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .

---

okay that's the whole page, bestie, we made it to the end 🥳 this one came to you courtesy of IEEE/The Open Group, dated 2017, and it's filed under DLCLOSE(3POSIX) in the POSIX Programmer's Manual. go forth and close your handles responsibly. mwah. 💋✨