1 .\" Copyright 1995 Yggdrasil Computing, Incorporated.
2 .\" written by Adam J. Richter (adam@yggdrasil.com),
3 .\" with typesetting help from Daniel Quinlan (quinlan@yggdrasil.com).
4 .\" and Copyright 2003, 2015 Michael Kerrisk <mtk.manpages@gmail.com>
6 .\" %%%LICENSE_START(GPLv2+_DOC_FULL)
7 .\" This is free documentation; you can redistribute it and/or
8 .\" modify it under the terms of the GNU General Public License as
9 .\" published by the Free Software Foundation; either version 2 of
10 .\" the License, or (at your option) any later version.
12 .\" The GNU General Public License's references to "object code"
13 .\" and "executables" are to be interpreted as the output of any
14 .\" document formatting or typesetting system, including
15 .\" intermediate and printed output.
17 .\" This manual is distributed in the hope that it will be useful,
18 .\" but WITHOUT ANY WARRANTY; without even the implied warranty of
19 .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
20 .\" GNU General Public License for more details.
22 .\" You should have received a copy of the GNU General Public
23 .\" License along with this manual; if not, see
24 .\" <http://www.gnu.org/licenses/>.
27 .\" Modified by David A. Wheeler <dwheeler@dwheeler.com> 2000-11-28.
28 .\" Applied patch by Terran Melconian, aeb, 2001-12-14.
29 .\" Modified by Hacksaw <hacksaw@hacksaw.org> 2003-03-13.
30 .\" Modified by Matt Domsch, 2003-04-09: _init and _fini obsolete
31 .\" Modified by Michael Kerrisk <mtk.manpages@gmail.com> 2003-05-16.
32 .\" Modified by Walter Harms: dladdr, dlvsym
33 .\" Modified by Petr Baudis <pasky@suse.cz>, 2008-12-04: dladdr caveat
35 .TH DLOPEN 3 2017-09-15 "Linux" "Linux Programmer's Manual"
37 dlclose, dlopen, dlmopen \-
38 open and close a shared object
42 .BI "void *dlopen(const char *" filename ", int " flags );
44 .BI "int dlclose(void *" handle );
46 .B #define _GNU_SOURCE
50 .BI "void *dlmopen (Lmid_t " lmid ", const char *" filename ", int " flags );
52 Link with \fI\-ldl\fP.
57 loads the dynamic shared object (shared library)
58 file named by the null-terminated
61 and returns an opaque "handle" for the loaded object.
62 This handle is employed with other functions in the dlopen API, such as
71 .\" FIXME On Solaris, when handle is NULL, we seem to get back
72 .\" a handle for (something like) the root of the namespace.
73 .\" The point here is that if we do a dlmopen(LM_ID_NEWLM), then
74 .\" the filename==NULL case returns a different handle than
75 .\" in the initial namespace. But, on glibc, the same handle is
76 .\" returned. This is probably a bug in glibc.
78 is NULL, then the returned handle is for the main program.
81 contains a slash ("/"), then it is interpreted as a (relative
82 or absolute) pathname.
83 Otherwise, the dynamic linker searches for the object as follows
88 (ELF only) If the executable file for the calling program
89 contains a DT_RPATH tag, and does not contain a DT_RUNPATH tag,
90 then the directories listed in the DT_RPATH tag are searched.
92 If, at the time that the program was started, the environment variable
94 was defined to contain a colon-separated list of directories,
95 then these are searched.
96 (As a security measure, this variable is ignored for set-user-ID and
97 set-group-ID programs.)
99 (ELF only) If the executable file for the calling program
100 contains a DT_RUNPATH tag, then the directories listed in that tag
107 is checked to see whether it contains an entry for
114 are searched (in that order).
116 If the object specified by
118 has dependencies on other shared objects,
119 then these are also automatically loaded by the dynamic linker
120 using the same rules.
121 (This process may occur recursively,
122 if those objects in turn have dependencies, and so on.)
124 One of the following two values must be included in
128 Perform lazy binding.
129 Resolve symbols only as the code that references them is executed.
130 If the symbol is never referenced, then it is never resolved.
131 (Lazy binding is performed only for function references;
132 references to variables are always immediately bound when
133 the shared object is loaded.)
135 .\" commit 12b5b6b7f78ea111e89bbf638294a5413c791072
136 this flag is overridden by the effect of the
138 environment variable.
141 If this value is specified, or the environment variable
143 is set to a nonempty string,
144 all undefined symbols in the shared object are resolved before
147 If this cannot be done, an error is returned.
149 Zero or more of the following values may also be ORed in
153 The symbols defined by this shared object will be
154 made available for symbol resolution of subsequently loaded shared objects.
157 This is the converse of
159 and the default if neither flag is specified.
160 Symbols defined in this shared object are not made available to resolve
161 references in subsequently loaded shared objects.
163 .BR RTLD_NODELETE " (since glibc 2.2)"
164 Do not unload the shared object during
166 Consequently, the object's static variables are not reinitialized
167 if the object is reloaded with
171 .BR RTLD_NOLOAD " (since glibc 2.2)"
172 Don't load the shared object.
173 This can be used to test if the object is already resident
175 returns NULL if it is not, or the object's handle if it is resident).
176 This flag can also be used to promote the flags on a shared object
177 that is already loaded.
178 For example, a shared object that was previously loaded with
181 .BR RTLD_NOLOAD\ |\ RTLD_GLOBAL .
184 .BR RTLD_DEEPBIND " (since glibc 2.3.4)"
185 .\" Inimitably described by UD in
186 .\" http://sources.redhat.com/ml/libc-hacker/2004-09/msg00083.html.
187 Place the lookup scope of the symbols in this
188 shared object ahead of the global scope.
189 This means that a self-contained object will use
190 its own symbols in preference to global symbols with the same name
191 contained in objects that have already been loaded.
195 is NULL, then the returned handle is for the main program.
198 this handle causes a search for a symbol in the main program,
199 followed by all shared objects loaded at program startup,
200 and then all shared objects loaded by
205 External references in the shared object are resolved using the
206 shared objects in that object's dependency list and any other
207 objects previously opened with the
210 If the executable was linked with the flag "\-rdynamic"
211 (or, synonymously, "\-\-export\-dynamic"),
212 then the global symbols in the executable will also be used
213 to resolve references in a dynamically loaded shared object.
215 If the same shared object is loaded again with
217 the same object handle is returned.
218 The dynamic linker maintains reference
219 counts for object handles, so a dynamically loaded shared object is not
222 has been called on it as many times as
225 Any initialization returns (see below) are called just once.
226 However, a subsequent
228 call that loads the same shared object with
230 may force symbol resolution for a shared object earlier loaded with
235 fails for any reason, it returns NULL.
238 This function performs the same task as
243 arguments, as well as the return value, are the same,
244 except for the differences noted below.
248 function differs from
250 primarily in that it accepts an additional argument,
252 that specifies the link-map list (also referred to as a
254 in which the shared object should be loaded.
257 adds the dynamically loaded shared object to the same namespace as
258 the shared object from which the
263 type is an opaque handle that refers to a namespace.
267 argument is either the ID of an existing namespace
268 .\" FIXME: Is using dlinfo() RTLD_DI_LMID the right technique?
269 (which can be obtained using the
272 request) or one of the following special values:
275 Load the shared object in the initial namespace
276 (i.e., the application's namespace).
279 Create a new namespace and load the shared object in that namespace.
280 The object must have been correctly linked
281 to reference all of the other shared objects that it requires,
282 since the new namespace is initially empty.
286 is NULL, then the only permitted value for
293 decrements the reference count on the
294 dynamically loaded shared object referred to by
296 If the reference count drops to zero,
297 then the object is unloaded.
298 All shared objects that were automatically loaded when
300 was invoked on the object referred to by
302 are recursively closed in the same manner.
304 A successful return from
306 does not guarantee that the symbols associated with
308 are removed from the caller's address space.
309 In addition to references resulting from explicit
311 calls, a shared object may have been implicitly loaded
312 (and reference counted) because of dependencies in other shared objects.
313 Only when all references have been released can the shared object
314 be removed from the address space.
320 return a non-NULL handle for the loaded library.
322 (file could not be found, was not readable, had the wrong format,
323 or caused errors during loading),
324 these functions return NULL.
328 returns 0; on error, it returns a nonzero value.
330 Errors from these functions can be diagnosed using
336 are present in glibc 2.0 and later.
338 first appeared in glibc 2.3.4.
340 For an explanation of the terms used in this section, see
346 Interface Attribute Value
351 T} Thread safety MT-Safe
354 POSIX.1-2001 describes
360 function is a GNU extension.
367 flags are GNU extensions;
368 the first two of these flags are also present on Solaris.
370 .SS dlmopen() and namespaces
371 A link-map list defines an isolated namespace for the
372 resolution of symbols by the dynamic linker.
374 dependent shared objects are implicitly loaded according to the usual rules,
375 and symbol references are likewise resolved according to the usual rules,
376 but such resolution is confined to the definitions provided by the
377 objects that have been (explicitly and implicitly) loaded into the namespace.
381 function permits object-load isolation\(emthe ability
382 to load a shared object in a new namespace without
383 exposing the rest of the application to the symbols
384 made available by the new object.
385 Note that the use of the
387 flag is not sufficient for this purpose,
388 since it prevents a shared object's symbols from being available to
392 we may want to make the symbols provided by a dynamically
393 loaded shared object available to (a subset of) other shared objects
394 without exposing those symbols to the entire application.
395 This can be achieved by using a separate namespace and the
401 function also can be used to provide better isolation than the
404 In particular, shared objects loaded with
408 if they are dependencies of another shared object loaded with
412 is insufficient to isolate a loaded shared object except in the (uncommon)
413 case where one has explicit control over all shared object dependencies.
417 are plugins where the author of the plugin-loading framework
418 can't trust the plugin authors and does not wish
419 any undefined symbols from the plugin framework to be resolved to plugin
421 Another use is to load the same object more than once.
424 this would require the creation of distinct copies of the shared object file.
427 this can be achieved by loading the same shared object file into
428 different namespaces.
430 The glibc implementation supports a maximum of
434 .SS Initialization and finalization functions
435 Shared objects may export functions using the
436 .B __attribute__((constructor))
438 .B __attribute__((destructor))
440 Constructor functions are executed before
442 returns, and destructor functions are executed before
445 A shared object may export multiple constructors and destructors,
446 and priorities can be associated with each function
447 to determine the order in which they are executed.
450 info pages (under "Function attributes")
451 .\" info gcc "C Extensions" "Function attributes"
452 for further information.
454 An older method of (partially) achieving the same result is via the use of
455 two special symbols recognized by the linker:
459 If a dynamically loaded shared object exports a routine named
461 then that code is executed after loading a shared object, before
464 If the shared object exports a routine named
466 then that routine is called just before the object is unloaded.
467 In this case, one must avoid linking against the system startup files,
468 which contain default versions of these files;
469 this can be done by using the
478 is now deprecated in favor of the aforementioned
479 constructors and destructors,
480 which among other advantages,
481 permit multiple initialization and finalization functions to be defined.
483 .\" Using these routines, or the gcc
484 .\" .B \-nostartfiles
487 .\" options, is not recommended.
488 .\" Their use may result in undesired behavior,
489 .\" since the constructor/destructor routines will not be executed
490 .\" (unless special measures are taken).
491 .\" .\" void _init(void) __attribute__((constructor));
492 .\" .\" void _fini(void) __attribute__((destructor));
497 can be used to register an exit handler that is automatically
498 called when a shared object is unloaded.
500 These functions are part of the dlopen API, derived from SunOS.
502 As at glibc 2.24, specifying the
506 .\" dlerror(): "invalid mode"
508 Furthermore, specifying
512 results in a program crash
514 if the call is made from any object loaded in a
515 namespace other than the initial namespace.
517 The program below loads the (glibc) math library,
518 looks up the address of the
520 function, and prints the cosine of 2.0.
521 The following is an example of building and running the program:
525 $ \fBcc dlopen_demo.c \-ldl\fP
536 #include <gnu/lib-names.h> /* Defines LIBM_SO (which will be a
537 string such as "libm.so.6") */
542 double (*cosine)(double);
545 handle = dlopen(LIBM_SO, RTLD_LAZY);
547 fprintf(stderr, "%s\en", dlerror());
551 dlerror(); /* Clear any existing error */
553 cosine = (double (*)(double)) dlsym(handle, "cos");
555 /* According to the ISO C standard, casting between function
556 pointers and 'void *', as done above, produces undefined results.
557 POSIX.1-2003 and POSIX.1-2008 accepted this state of affairs and
558 proposed the following workaround:
560 *(void **) (&cosine) = dlsym(handle, "cos");
562 This (clumsy) cast conforms with the ISO C standard and will
563 avoid any compiler warnings.
565 The 2013 Technical Corrigendum to POSIX.1-2008 (a.k.a.
566 POSIX.1-2013) improved matters by requiring that conforming
567 implementations support casting 'void *' to a function pointer.
568 Nevertheless, some compilers (e.g., gcc with the '-pedantic'
569 option) may complain about the cast used in this program. */
570 .\" http://pubs.opengroup.org/onlinepubs/009695399/functions/dlsym.html#tag_03_112_08
571 .\" http://pubs.opengroup.org/onlinepubs/9699919799/functions/dlsym.html#tag_16_96_07
572 .\" http://austingroupbugs.net/view.php?id=74
576 fprintf(stderr, "%s\en", error);
580 printf("%f\en", (*cosine)(2.0));
589 .BR dl_iterate_phdr (3),
598 gcc info pages, ld info pages