1.\" This source code is a product of Sun Microsystems, Inc. and is provided 2.\" for unrestricted use provided that this legend is included on all tape 3.\" media and as a part of the software program in whole or part. Users 4.\" may copy or modify this source code without charge, but are not authorized 5.\" to license or distribute it to anyone else except as part of a product or 6.\" program developed by the user. 7.\" 8.\" THIS PROGRAM CONTAINS SOURCE CODE COPYRIGHTED BY SUN MICROSYSTEMS, INC. 9.\" SUN MICROSYSTEMS, INC., MAKES NO REPRESENTATIONS ABOUT THE SUITABLITY 10.\" OF SUCH SOURCE CODE FOR ANY PURPOSE. IT IS PROVIDED "AS IS" WITHOUT 11.\" EXPRESS OR IMPLIED WARRANTY OF ANY KIND. SUN MICROSYSTEMS, INC. DISCLAIMS 12.\" ALL WARRANTIES WITH REGARD TO SUCH SOURCE CODE, INCLUDING ALL IMPLIED 13.\" WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN 14.\" NO EVENT SHALL SUN MICROSYSTEMS, INC. BE LIABLE FOR ANY SPECIAL, INDIRECT, 15.\" INCIDENTAL, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING 16.\" FROM USE OF SUCH SOURCE CODE, REGARDLESS OF THE THEORY OF LIABILITY. 17.\" 18.\" This source code is provided with no support and without any obligation on 19.\" the part of Sun Microsystems, Inc. to assist in its use, correction, 20.\" modification or enhancement. 21.\" 22.\" SUN MICROSYSTEMS, INC. SHALL HAVE NO LIABILITY WITH RESPECT TO THE 23.\" INFRINGEMENT OF COPYRIGHTS, TRADE SECRETS OR ANY PATENTS BY THIS 24.\" SOURCE CODE OR ANY PART THEREOF. 25.\" 26.\" Sun Microsystems, Inc. 27.\" 2550 Garcia Avenue 28.\" Mountain View, California 94043 29.\" 30.\" Copyright (c) 1991 Sun Microsystems, Inc. 31.\" 32.\" @(#) dlopen.3 1.6 90/01/31 SMI 33.\" $FreeBSD$ 34.\" 35.Dd May 28, 2002 36.Os 37.Dt DLOPEN 3 38.Sh NAME 39.Nm dlopen , dlsym , dlfunc , dlerror , dlclose 40.Nd programmatic interface to the dynamic linker 41.Sh LIBRARY 42.Lb libc 43.Sh SYNOPSIS 44.In dlfcn.h 45.Ft void * 46.Fn dlopen "const char *path" "int mode" 47.Ft void * 48.Fn dlsym "void *handle" "const char *symbol" 49.Ft dlfunc_t 50.Fn dlfunc "void *handle" "const char *symbol" 51.Ft const char * 52.Fn dlerror "void" 53.Ft int 54.Fn dlclose "void *handle" 55.Sh DESCRIPTION 56These functions provide a simple programmatic interface to the services of the 57dynamic linker. 58Operations are provided to add new shared objects to a 59program's address space, to obtain the address bindings of symbols 60defined by such 61objects, and to remove such objects when their use is no longer required. 62.Pp 63.Fn dlopen 64provides access to the shared object in 65.Fa path , 66returning a descriptor that can be used for later 67references to the object in calls to 68.Fn dlsym 69and 70.Fn dlclose . 71If 72.Fa path 73was not in the address space prior to the call to 74.Fn dlopen , 75it is placed in the address space. 76When an object is first loaded into the address space in this way, its 77function 78.Fn _init , 79if any, is called by the dynamic linker. 80If 81.Fa path 82has already been placed in the address space in a previous call to 83.Fn dlopen , 84it is not added a second time, although a reference count of 85.Fn dlopen 86operations on 87.Fa path 88is maintained. 89A null pointer supplied for 90.Fa path 91is interpreted as a reference to the main 92executable of the process. 93.Fa mode 94controls the way in which external function references from the 95loaded object are bound to their referents. 96It must contain one of the following values, possibly ORed with 97additional flags which will be described subsequently: 98.Bl -tag -width RTLD_LAZYX 99.It Dv RTLD_LAZY 100Each external function reference is resolved when the function is first 101called. 102.It Dv RTLD_NOW 103All external function references are bound immediately by 104.Fn dlopen . 105.El 106.Pp 107.Dv RTLD_LAZY 108is normally preferred, for reasons of efficiency. 109However, 110.Dv RTLD_NOW 111is useful to ensure that any undefined symbols are discovered during the 112call to 113.Fn dlopen . 114.Pp 115One of the following flags may be ORed into the 116.Fa mode 117argument: 118.Bl -tag -width RTLD_GLOBALX 119.It Dv RTLD_GLOBAL 120Symbols from this shared object and its directed acyclic graph (DAG) 121of needed objects will be available for resolving undefined references 122from all other shared objects. 123.It Dv RTLD_LOCAL 124Symbols in this shared object and its DAG of needed objects will be 125available for resolving undefined references only from other objects 126in the same DAG. 127This is the default, but it may be specified 128explicitly with this flag. 129.It Dv RTLD_TRACE 130When set, causes dynamic linker to exit after loading all objects 131needed by this shared object and printing a summary which includes 132the absolute pathnames of all objects, to standard output. 133With this flag 134.Fn dlopen 135will return to the caller only in the case of error. 136.El 137.Pp 138If 139.Fn dlopen 140fails, it returns a null pointer, and sets an error condition which may 141be interrogated with 142.Fn dlerror . 143.Pp 144.Fn dlsym 145returns the address binding of the symbol described in the null-terminated 146character string 147.Fa symbol , 148as it occurs in the shared object identified by 149.Fa handle . 150The symbols exported by objects added to the address space by 151.Fn dlopen 152can be accessed only through calls to 153.Fn dlsym . 154Such symbols do not supersede any definition of those symbols already present 155in the address space when the object is loaded, nor are they available to 156satisfy normal dynamic linking references. 157.Pp 158If 159.Fn dlsym 160is called with the special 161.Fa handle 162.Dv NULL , 163it is interpreted as a reference to the executable or shared object 164from which the call 165is being made. 166Thus a shared object can reference its own symbols. 167.Pp 168If 169.Fn dlsym 170is called with the special 171.Fa handle 172.Dv RTLD_DEFAULT , 173the search for the symbol follows the algorithm used for resolving 174undefined symbols when objects are loaded. 175The objects searched are 176as follows, in the given order: 177.Bl -enum 178.It 179The referencing object itself (or the object from which the call to 180.Fn dlsym 181is made), if that object was linked using the 182.Fl Wsymbolic 183option to 184.Xr ld 1 . 185.It 186All objects loaded at program start-up. 187.It 188All objects loaded via 189.Fn dlopen 190which are in needed-object DAGs that also contain the referencing object. 191.It 192All objects loaded via 193.Fn dlopen 194with the 195.Dv RTLD_GLOBAL 196flag set in the 197.Fa mode 198argument. 199.El 200.Pp 201If 202.Fn dlsym 203is called with the special 204.Fa handle 205.Dv RTLD_NEXT , 206then the search for the symbol is limited to the shared objects 207which were loaded after the one issuing the call to 208.Fn dlsym . 209Thus, if the function is called from the main program, all 210the shared libraries are searched. 211If it is called from a shared library, all subsequent shared 212libraries are searched. 213.Dv RTLD_NEXT 214is useful for implementing wrappers around library functions. 215For example, a wrapper function 216.Fn getpid 217could access the 218.Dq real 219.Fn getpid 220with 221.Li dlsym(RTLD_NEXT, \&"getpid\&") . 222(Actually, the 223.Fn dlfunc 224interface, below, should be used, since 225.Fn getpid 226is a function and not a data object.) 227.Pp 228.Fn dlsym 229returns a null pointer if the symbol cannot be found, and sets an error 230condition which may be queried with 231.Fn dlerror . 232.Pp 233.Fn dlfunc 234implements all of the behavior of 235.Fn dlsym , 236but has a return type which can be cast to a function pointer without 237triggering compiler diagnostics. 238.Fn ( dlsym 239returns a data pointer; in the C standard, conversions between 240data and function pointer types are undefined. 241Some compilers and 242.Xr lint 1 243utilities warn about such casts.) 244The precise return type of 245.Fn dlfunc 246is unspecified; applications must cast it to an appropriate function pointer 247type. 248.Pp 249.Fn dlerror 250returns a null-terminated character string describing the last error that 251occurred during a call to 252.Fn dlopen , 253.Fn dlsym , 254.Fn dlfunc , 255or 256.Fn dlclose . 257If no such error has occurred, 258.Fn dlerror 259returns a null pointer. 260At each call to 261.Fn dlerror , 262the error indication is reset. 263Thus in the case of two calls 264to 265.Fn dlerror , 266where the second call follows the first immediately, the second call 267will always return a null pointer. 268.Pp 269.Fn dlclose 270deletes a reference to the shared object referenced by 271.Fa handle . 272If the reference count drops to 0, the object is removed from the 273address space, and 274.Fa handle 275is rendered invalid. 276Just before removing a shared object in this way, the dynamic linker 277calls the object's 278.Fn _fini 279function, if such a function is defined by the object. 280If 281.Fn dlclose 282is successful, it returns a value of 0. 283Otherwise it returns -1, and sets an error condition that can be 284interrogated with 285.Fn dlerror . 286.Pp 287The object-intrinsic functions 288.Fn _init 289and 290.Fn _fini 291are called with no arguments, and are not expected to return values. 292.Sh NOTES 293ELF executables need to be linked 294using the 295.Fl export-dynamic 296option to 297.Xr ld 1 298for symbols defined in the executable to become visible to 299.Fn dlsym . 300.Pp 301In previous implementations, it was necessary to prepend an underscore 302to all external symbols in order to gain symbol 303compatibility with object code compiled from the C language. 304This is 305still the case when using the (obsolete) 306.Fl aout 307option to the C language compiler. 308.Sh ERRORS 309.Fn dlopen , 310.Fn dlsym , 311and 312.Fn dlfunc 313return a null pointer in the event of errors. 314.Fn dlclose 315returns 0 on success, or -1 if an error occurred. 316Whenever an error has been detected, a message detailing it can be 317retrieved via a call to 318.Fn dlerror . 319.Sh SEE ALSO 320.Xr ld 1 , 321.Xr rtld 1 , 322.Xr dladdr 3 , 323.Xr link 5 324