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.Dd September 24, 1989 34.Os FreeBSD 35.Dt DLOPEN 3 36.Sh NAME 37.Nm dlopen, dlsym, dlerror, dlclose 38.Nd programmatic interface to the dynamic linker 39.Sh SYNOPSIS 40.Fd #include <dlfcn.h> 41.Ft void * 42.Fn dlopen "const char *path" "int mode" 43.Ft void * 44.Fn dlsym "void *handle" "const char *symbol" 45.Ft const char * 46.Fn dlerror "void" 47.Ft int 48.Fn dlclose "void *handle" 49.Sh DESCRIPTION 50These functions provide a simple programmatic interface to the services of the 51dynamic linker. 52Operations are provided to add new shared objects to a 53program's address space, to obtain the address bindings of symbols 54defined by such 55objects, and to remove such objects when their use is no longer required. 56.Pp 57.Fn dlopen 58provides access to the shared object in 59.Fa path , 60returning a descriptor that can be used for later 61references to the object in calls to 62.Fn dlsym 63and 64.Fn dlclose . 65If 66.Fa path 67was not in the address space prior to the call to 68.Fn dlopen , 69it is placed in the address space. 70When an object is first loaded into the address space in this way, its 71function 72.Fn _init , 73if any, is called by the dynamic linker. 74(Note that 75.Ql _init 76is the name as expressed in the C language. 77From assembly language, the name would appear as 78.Ql __init 79instead.) 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: 97.Bl -tag -width RTLD_LAZYX 98.It Dv RTLD_LAZY 99Each external function reference is resolved when the function is first 100called. 101.It Dv RTLD_NOW 102All external function references are bound immediately by 103.Fn dlopen . 104.El 105.Pp 106.Dv RTLD_LAZY 107is normally preferred, for reasons of efficiency. 108However, 109.Dv RTLD_NOW 110is useful to ensure that any undefined symbols are discovered during the 111call to 112.Fn dlopen . 113If 114.Fn dlopen 115fails, it returns a null pointer, and sets an error condition which may 116be interrogated with 117.Fn dlerror . 118.Pp 119.Fn dlsym 120returns the address binding of the symbol described in the null-terminated 121character string 122.Fa symbol , 123as it occurs in the shared object identified by 124.Fa handle . 125Note that 126.Fa symbol 127is the assembly language representation of the symbol name. 128The assembly language representation of a C language symbol contains an 129extra underscore at the beginning. 130For example, the symbol 131.Ql foo 132in C would appear as 133.Ql _foo 134in assembly language, and in the 135.Fa symbol 136argument to 137.Fn dlsym . 138The symbols exported by objects added to the address space by 139.Fn dlopen 140can be accessed only through calls to 141.Fn dlsym . 142Such symbols do not supersede any definition of those symbols already present 143in the address space when the object is loaded, nor are they available to 144satisfy normal dynamic linking references. 145A null pointer supplied as the value of 146.Fa handle 147is interpreted as a reference to the executable from which the call to 148.Fn dlsym 149is being made. Thus a shared object can reference its own symbols. 150.Fn dlsym 151returns a null pointer if the symbol cannot be found, and sets an error 152condition which may be queried with 153.Fn dlerror . 154.Pp 155If 156.Fn dlsym 157is called with the special 158.Fa handle 159.Dv RTLD_NEXT , 160then the search for the symbol is limited to the shared objects 161which were loaded after the one issuing the call to 162.Fn dlsym . 163Thus, if the function is called from the main program, all 164the shared libraries are searched. 165If it is called from a shared library, all subsequent shared 166libraries are searched. 167.Dv RTLD_NEXT 168is useful for implementing wrappers around library functions. 169For example, a wrapper function 170.Fn getpid 171could access the 172.Dq real 173.Fn getpid 174with 175.Li dlsym(RTLD_NEXT, \&"_getpid\&") . 176.Pp 177.Fn dlerror 178returns a null-terminated character string describing the last error that 179occurred during a call to 180.Fn dlopen , 181.Fn dlsym , 182or 183.Fn dlclose . 184If no such error has occurred, 185.Fn dlerror 186returns a null pointer. 187At each call to 188.Fn dlerror , 189the error indication is reset. Thus in the case of two calls 190to 191.Fn dlerror , 192where the second call follows the first immediately, the second call 193will always return a null pointer. 194.Pp 195.Fn dlclose 196deletes a reference to the shared object referenced by 197.Fa handle . 198If the reference count drops to 0, the object is removed from the 199address space, and 200.Fa handle 201is rendered invalid. 202Just before removing a shared object in this way, the dynamic linker 203calls the object's 204.Fn _fini 205function, if such a function is defined by the object. 206As with 207.Ql _init , 208.Ql _fini 209is the C language name of the function. 210If 211.Fn dlclose 212is successful, it returns a value of 0. 213Otherwise it returns -1, and sets an error condition that can be 214interrogated with 215.Fn dlerror . 216.Pp 217The object-intrinsic functions 218.Fn _init 219and 220.Fn _fini 221are called with no arguments, and are not expected to return values. 222.Sh NOTES 223ELF executables need to be linked 224using the 225.Fl export-dynamic 226option to 227.Xr ld 1 228for symbols defined in the executable to become visible to 229.Fn dlsym . 230.Sh ERRORS 231.Fn dlopen 232and 233.Fn dlsym 234return the null pointer in the event of errors. 235.Fn dlclose 236returns 0 on success, or -1 if an error occurred. 237Whenever an error has been detected, a message detailing it can be 238retrieved via a call to 239.Fn dlerror . 240.Sh SEE ALSO 241.Xr ld 1 , 242.Xr rtld 1 , 243.Xr link 5 244 245