DLSYM(3P)

💖 DLSYM(3P) — POSIX Programmer's Manual 💖

okay bestie, welcome to dlsym(3P) from the POSIX Programmer's Manual 🎀 this one is literally the "hey can I get the address of that symbol pls" function and she's iconic.

---

✨ PROLOG ✨

okay so real talk first — this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (so like, go consult the corresponding Linux manual page for the deets on Linux behavior), or honestly the interface may not be implemented on Linux at all. vibe check accordingly 🫶

---

✨ NAME ✨

dlsym — get the address of a symbol from a symbol table handle 🦋

---

✨ SYNOPSIS ✨

#include <dlfcn.h>

void *dlsym(void *restrict handle, const char *restrict name);

---

✨ DESCRIPTION ✨

okay so here's the tea ☕ The dlsym() function shall obtain the address of a symbol (which is either a function identifier or a data object identifier) defined in the symbol table identified by the handle argument.

And what even is handle? She's a symbol table handle returned from a call to dlopen() — and importantly, one that has not since been released by a call to dlclose(). And name is the symbol's name, as a character string. 💅

The return value from dlsym(), cast to a pointer to the type of the named symbol, can be used to:

• call it (in the case of a function), or
• access the contents of it (in the case of a data object)

the named symbol. slay.

The dlsym() function shall search for the named symbol in the symbol table referenced by handle. If the symbol table was created with lazy loading (see RTLD_LAZY in dlopen()), then load ordering shall be used in dlsym() operations to relocate executable object files needed to resolve the symbol. And the symbol resolution algorithm used shall be dependency order, as described in dlopen(). iykyk 🌈

Now — the RTLD_DEFAULT and RTLD_NEXT symbolic constants (which may be defined in <dlfcn.h>) are reserved for future use as special values that applications may be allowed to use for handle. so like, don't get too comfy with them yet bestie 🙈

---

✨ RETURN VALUE ✨

Upon successful completion:

• if name names a function identifier, dlsym() shall return the address of the function converted from type pointer to function to type pointer to void;
• otherwise, dlsym() shall return the address of the data object associated with the data object identifier named by name, converted from a pointer to the type of the data object to a pointer to void.

And if handle does not refer to a valid symbol table handle, or if the symbol named by name cannot be found in the symbol table associated with handle, then dlsym() shall return a null pointer. 😭

Also!! More detailed diagnostic information shall be available through dlerror(). so go ask her for the gossip 🔍

---

✨ ERRORS ✨

No errors are defined. 💀 that's it, that's the section.

The following sections are informative. (translation: the rest is bonus content, not the law 📜)

---

✨ EXAMPLES ✨

okay this example is so good, she shows how dlopen() and dlsym() can be used to access either a function or a data object. For simplicity, error checking has been omitted. (not me skipping error checking, do as I say not as I do 🙈)

void *handle;
int (*fptr)(int), *iptr, result;
/* open the needed symbol table */
handle = dlopen("/usr/home/me/libfoo.so", RTLD_LOCAL | RTLD_LAZY);
/* find the address of the function my_function */
fptr = (int (*)(int))dlsym(handle, "my_function");
/* find the address of the data object my_object */
iptr = (int *)dlsym(handle, "my_OBJ");
/* invoke my_function, passing the value of my_OBJ as the parameter */
result = (*fptr)(*iptr);

---

✨ APPLICATION USAGE ✨

The following special purpose values for handle are reserved for future use and have the indicated meanings:

• RTLD_DEFAULT — The identifier lookup happens in the normal global scope; that is, a search for an identifier using handle would find the same definition as a direct use of this identifier in the program code.
• RTLD_NEXT — Specifies the next executable object file after this one that defines name. This one refers to the executable object file containing the invocation of dlsym(). The next executable object file is the one found upon the application of a load order symbol resolution algorithm (see dlopen()). The next symbol is either one of global scope (because it was introduced as part of the original process image or because it was added with a dlopen() operation including the RTLD_GLOBAL flag), or is in an executable object file that was included in the same dlopen() operation that loaded this one.

The RTLD_NEXT flag is useful to navigate an intentionally created hierarchy of multiply-defined symbols created through interposition. For example, if a program wished to create an implementation of malloc() that embedded some statistics gathering about memory allocations, such an implementation could use the real malloc() definition to perform the memory allocation — and itself only embed the necessary logic to implement the statistics gathering function. main character energy fr fr 👑

⚠️ Note that conversion from a void * pointer to a function pointer as in:

fptr = (int (*)(int))dlsym(handle, "my_function");

is not defined by the ISO C standard. This standard requires this conversion to work correctly on conforming implementations. so like... technically cursed, but POSIX says it has to work. no cap 🔥

---

✨ RATIONALE ✨

None. 💅 (she said nothing, your honor)

---

✨ FUTURE DIRECTIONS ✨

None. 🦋 (nothing coming, bestie, we're chilling)

---

✨ SEE ALSO ✨

• dlclose()
• dlerror()
• dlopen()

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 .

---

and that's the whole page bestie!! 🎀✨ this diva came to you from IEEE/The Open Group, 2017 — thanks for reading, ily, go call dlsym() responsibly 💖🦋