lib/libc/gen/dlopen.3

   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 July 7, 2009
  36 .Os
  37 .Dt DLOPEN 3
  38 .Sh NAME
  39 .Nm dlopen ,
  40 .Nm dlsym ,
  41 .Nm dlfunc ,
  42 .Nm dlerror ,
  43 .Nm dlclose
  44 .Nd programmatic interface to the dynamic linker
  45 .Sh LIBRARY
  46 .Lb libc
  47 .Sh SYNOPSIS
  48 .In dlfcn.h
  49 .Ft void *
  50 .Fn dlopen "const char *path" "int mode"
  51 .Ft void *
  52 .Fn dlsym "void * restrict handle" "const char * restrict symbol"
  53 .Ft dlfunc_t
  54 .Fn dlfunc "void * restrict handle" "const char * restrict symbol"
  55 .Ft char *
  56 .Fn dlerror "void"
  57 .Ft int
  58 .Fn dlclose "void *handle"
  59 .Sh DESCRIPTION
  60 These functions provide a simple programmatic interface to the services of the
  61 dynamic linker.
  62 Operations are provided to add new shared objects to a
  63 program's address space, to obtain the address bindings of symbols
  64 defined by such
  65 objects, and to remove such objects when their use is no longer required.
  66 .Pp
  67 The
  68 .Fn dlopen
  69 function
  70 provides access to the shared object in
  71 .Fa path ,
  72 returning a descriptor that can be used for later
  73 references to the object in calls to
  74 .Fn dlsym
  75 and
  76 .Fn dlclose .
  77 If
  78 .Fa path
  79 was not in the address space prior to the call to
  80 .Fn dlopen ,
  81 it is placed in the address space.
  82 When an object is first loaded into the address space in this way, its
  83 function
  84 .Fn _init ,
  85 if any, is called by the dynamic linker.
  86 If
  87 .Fa path
  88 has already been placed in the address space in a previous call to
  89 .Fn dlopen ,
  90 it is not added a second time, although a reference count of
  91 .Fn dlopen
  92 operations on
  93 .Fa path
  94 is maintained.
  95 A null pointer supplied for
  96 .Fa path
  97 is interpreted as a reference to the main
  98 executable of the process.
  99 The
 100 .Fa mode
 101 argument
 102 controls the way in which external function references from the
 103 loaded object are bound to their referents.
 104 It must contain one of the following values, possibly ORed with
 105 additional flags which will be described subsequently:
 106 .Bl -tag -width RTLD_LAZYX
 107 .It Dv RTLD_LAZY
 108 Each external function reference is resolved when the function is first
 109 called.
 110 .It Dv RTLD_NOW
 111 All external function references are bound immediately by
 112 .Fn dlopen .
 113 .El
 114 .Pp
 115 .Dv RTLD_LAZY
 116 is normally preferred, for reasons of efficiency.
 117 However,
 118 .Dv RTLD_NOW
 119 is useful to ensure that any undefined symbols are discovered during the
 120 call to
 121 .Fn dlopen .
 122 .Pp
 123 One of the following flags may be ORed into the
 124 .Fa mode
 125 argument:
 126 .Bl -tag -width RTLD_NODELETE
 127 .It Dv RTLD_GLOBAL
 128 Symbols from this shared object and its directed acyclic graph (DAG)
 129 of needed objects will be available for resolving undefined references
 130 from all other shared objects.
 131 .It Dv RTLD_LOCAL
 132 Symbols in this shared object and its DAG of needed objects will be
 133 available for resolving undefined references only from other objects
 134 in the same DAG.
 135 This is the default, but it may be specified
 136 explicitly with this flag.
 137 .It Dv RTLD_TRACE
 138 When set, causes dynamic linker to exit after loading all objects
 139 needed by this shared object and printing a summary which includes
 140 the absolute pathnames of all objects, to standard output.
 141 With this flag
 142 .Fn dlopen
 143 will return to the caller only in the case of error.
 144 .It Dv RTLD_NODELETE
 145 Prevents unload of the loaded object on
 146 .Fn dlclose .
 147 The same behaviour may be requested by
 148 .Fl "z nodelete"
 149 option of the static linker
 150 .Xr ld 1 .
 151 .It Dv RTLD_NOLOAD
 152 Ony return valid handle for the object if it is already loaded in
 153 the process address space, otherwise
 154 .Dv NULL
 155 is returned.
 156 Other mode flags may be specified, which will be applied for promotion
 157 for the found object.
 158 .El
 159 .Pp
 160 If
 161 .Fn dlopen
 162 fails, it returns a null pointer, and sets an error condition which may
 163 be interrogated with
 164 .Fn dlerror .
 165 .Pp
 166 The
 167 .Fn dlsym
 168 function
 169 returns the address binding of the symbol described in the null-terminated
 170 character string
 171 .Fa symbol ,
 172 as it occurs in the shared object identified by
 173 .Fa handle .
 174 The symbols exported by objects added to the address space by
 175 .Fn dlopen
 176 can be accessed only through calls to
 177 .Fn dlsym .
 178 Such symbols do not supersede any definition of those symbols already present
 179 in the address space when the object is loaded, nor are they available to
 180 satisfy normal dynamic linking references.
 181 .Pp
 182 If
 183 .Fn dlsym
 184 is called with the special
 185 .Fa handle
 186 .Dv NULL ,
 187 it is interpreted as a reference to the executable or shared object
 188 from which the call
 189 is being made.
 190 Thus a shared object can reference its own symbols.
 191 .Pp
 192 If
 193 .Fn dlsym
 194 is called with the special
 195 .Fa handle
 196 .Dv RTLD_DEFAULT ,
 197 the search for the symbol follows the algorithm used for resolving
 198 undefined symbols when objects are loaded.
 199 The objects searched are
 200 as follows, in the given order:
 201 .Bl -enum
 202 .It
 203 The referencing object itself (or the object from which the call to
 204 .Fn dlsym
 205 is made), if that object was linked using the
 206 .Fl Wsymbolic
 207 option to
 208 .Xr ld 1 .
 209 .It
 210 All objects loaded at program start-up.
 211 .It
 212 All objects loaded via
 213 .Fn dlopen
 214 with the
 215 .Dv RTLD_GLOBAL
 216 flag set in the
 217 .Fa mode
 218 argument.
 219 .It
 220 All objects loaded via
 221 .Fn dlopen
 222 which are in needed-object DAGs that also contain the referencing object.
 223 .El
 224 .Pp
 225 If
 226 .Fn dlsym
 227 is called with the special
 228 .Fa handle
 229 .Dv RTLD_NEXT ,
 230 then the search for the symbol is limited to the shared objects
 231 which were loaded after the one issuing the call to
 232 .Fn dlsym .
 233 Thus, if the function is called from the main program, all
 234 the shared libraries are searched.
 235 If it is called from a shared library, all subsequent shared
 236 libraries are searched.
 237 .Dv RTLD_NEXT
 238 is useful for implementing wrappers around library functions.
 239 For example, a wrapper function
 240 .Fn getpid
 241 could access the
 242 .Dq real
 243 .Fn getpid
 244 with
 245 .Li dlsym(RTLD_NEXT, \&"getpid\&") .
 246 (Actually, the
 247 .Fn dlfunc
 248 interface, below, should be used, since
 249 .Fn getpid
 250 is a function and not a data object.)
 251 .Pp
 252 If
 253 .Fn dlsym
 254 is called with the special
 255 .Fa handle
 256 .Dv RTLD_SELF ,
 257 then the search for the symbol is limited to the shared object
 258 issuing the call to
 259 .Fn dlsym
 260 and those shared objects which were loaded after it.
 261 .Pp
 262 The
 263 .Fn dlsym
 264 function
 265 returns a null pointer if the symbol cannot be found, and sets an error
 266 condition which may be queried with
 267 .Fn dlerror .
 268 .Pp
 269 The
 270 .Fn dlfunc
 271 function
 272 implements all of the behavior of
 273 .Fn dlsym ,
 274 but has a return type which can be cast to a function pointer without
 275 triggering compiler diagnostics.
 276 (The
 277 .Fn dlsym
 278 function
 279 returns a data pointer; in the C standard, conversions between
 280 data and function pointer types are undefined.
 281 Some compilers and
 282 .Xr lint 1
 283 utilities warn about such casts.)
 284 The precise return type of
 285 .Fn dlfunc
 286 is unspecified; applications must cast it to an appropriate function pointer
 287 type.
 288 .Pp
 289 The
 290 .Fn dlerror
 291 function
 292 returns a null-terminated character string describing the last error that
 293 occurred during a call to
 294 .Fn dlopen ,
 295 .Fn dladdr ,
 296 .Fn dlinfo ,
 297 .Fn dlsym ,
 298 .Fn dlfunc ,
 299 or
 300 .Fn dlclose .
 301 If no such error has occurred,
 302 .Fn dlerror
 303 returns a null pointer.
 304 At each call to
 305 .Fn dlerror ,
 306 the error indication is reset.
 307 Thus in the case of two calls
 308 to
 309 .Fn dlerror ,
 310 where the second call follows the first immediately, the second call
 311 will always return a null pointer.
 312 .Pp
 313 The
 314 .Fn dlclose
 315 function
 316 deletes a reference to the shared object referenced by
 317 .Fa handle .
 318 If the reference count drops to 0, the object is removed from the
 319 address space, and
 320 .Fa handle
 321 is rendered invalid.
 322 Just before removing a shared object in this way, the dynamic linker
 323 calls the object's
 324 .Fn _fini
 325 function, if such a function is defined by the object.
 326 If
 327 .Fn dlclose
 328 is successful, it returns a value of 0.
 329 Otherwise it returns -1, and sets an error condition that can be
 330 interrogated with
 331 .Fn dlerror .
 332 .Pp
 333 The object-intrinsic functions
 334 .Fn _init
 335 and
 336 .Fn _fini
 337 are called with no arguments, and are not expected to return values.
 338 .Sh NOTES
 339 ELF executables need to be linked
 340 using the
 341 .Fl export-dynamic
 342 option to
 343 .Xr ld 1
 344 for symbols defined in the executable to become visible to
 345 .Fn dlsym .
 346 .Pp
 347 In previous implementations, it was necessary to prepend an underscore
 348 to all external symbols in order to gain symbol
 349 compatibility with object code compiled from the C language.
 350 This is
 351 still the case when using the (obsolete)
 352 .Fl aout
 353 option to the C language compiler.
 354 .Sh ERRORS
 355 The
 356 .Fn dlopen ,
 357 .Fn dlsym ,
 358 and
 359 .Fn dlfunc
 360 functions
 361 return a null pointer in the event of errors.
 362 The
 363 .Fn dlclose
 364 function
 365 returns 0 on success, or -1 if an error occurred.
 366 Whenever an error has been detected, a message detailing it can be
 367 retrieved via a call to
 368 .Fn dlerror .
 369 .Sh SEE ALSO
 370 .Xr ld 1 ,
 371 .Xr rtld 1 ,
 372 .Xr dladdr 3 ,
 373 .Xr dlinfo 3 ,
 374 .Xr link 5