DLCLOSE(3P)

πŸ’– DLCLOSE(3P) β€” the POSIX Programmer's Manual glow-up πŸ’–

okay bestie, so this is dlclose(3P) straight out of the POSIX Programmer's Manual, and before we even get into it, here's the tea you need:

⚠️ PROLOG β€” 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 might not even be implemented on Linux at all. πŸ™ˆ

✨ NAME ✨

dlclose β€” close a symbol table handle


πŸŽ€ SYNOPSIS πŸŽ€

#include <dlfcn.h>

int dlclose(void *handle);

πŸ¦‹ DESCRIPTION πŸ¦‹

So like, dlclose() tells the system that the symbol table handle you passed in as handle? no longer needed by the application. bye babe πŸ’…

An application writer may use dlclose() to make a statement of intent on behalf of the process β€” but ngl, that statement does not create any requirement upon the implementation. It's giving "I'm done with this" energy, not "you MUST do this" energy.

When the symbol table handle is closed, the implementation may unload the executable object files that were loaded by dlopen() when that symbol table handle was opened β€” and also those that were loaded by dlsym() when using the symbol table handle identified by handle.

Once a symbol table handle has been closed, an application should assume that any symbols (function identifiers and data object identifiers) that were made visible using handle are no longer available to the process. gone. ghosted. ✨

Now here's the nuanced part, bestie, stay with me: 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.

Example time, fr fr: 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.


🌈 RETURN VALUE 🌈

  • If the referenced symbol table handle was successfully closed, dlclose() shall return 0. πŸŽ‰
  • 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(). 🫢

πŸ’œ ERRORS πŸ’œ

No errors are defined.

The following sections are informative. (so like, the vibe sections, not the rules sections ✨)


πŸ“ 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);
...

iconic honestly. open the lib, do your thing, close the lib. main character arc. πŸ‘‘


🧚 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, handle.

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 don't be out here assuming every dlopen() hands you a fresh lil baby handle.

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(). don't peek inside, don't compare them, don't be nosy. 🚫


⭐ RATIONALE ⭐

None.


πŸ”₯ FUTURE DIRECTIONS πŸ”₯

None.


πŸ‘‘ SEE ALSO πŸ‘‘

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

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


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, we ate and left no crumbs πŸ’… and just so you know who's behind all this: IEEE/The Open Group, 2017, DLCLOSE(3P). mwah, go close some handles responsibly bestie πŸ«ΆπŸ’–

πŸ“¦ where this page comes from