1.\" $OpenBSD: dlfcn.3,v 1.36 2024/09/01 04:27:45 guenther Exp $ 2.\" $NetBSD: dlfcn.3,v 1.3 1996/01/09 19:43:34 pk Exp $ 3.\" 4.\" Copyright (c) 1995 Paul Kranenburg 5.\" All rights reserved. 6.\" 7.\" Redistribution and use in source and binary forms, with or without 8.\" modification, are permitted provided that the following conditions 9.\" are met: 10.\" 1. Redistributions of source code must retain the above copyright 11.\" notice, this list of conditions and the following disclaimer. 12.\" 2. Redistributions in binary form must reproduce the above copyright 13.\" notice, this list of conditions and the following disclaimer in the 14.\" documentation and/or other materials provided with the distribution. 15.\" 3. All advertising materials mentioning features or use of this software 16.\" must display the following acknowledgement: 17.\" This product includes software developed by Paul Kranenburg. 18.\" 3. The name of the author may not be used to endorse or promote products 19.\" derived from this software without specific prior written permission 20.\" 21.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR 22.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES 23.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. 24.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, 25.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 26.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 27.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 28.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 29.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 30.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 31.\" 32.Dd $Mdocdate: September 1 2024 $ 33.Dt DLOPEN 3 34.Os 35.Sh NAME 36.Nm dlopen , 37.Nm dlclose , 38.Nm dlsym , 39.Nm dladdr , 40.Nm dlctl , 41.Nm dlerror 42.Nd dynamic link interface 43.Sh SYNOPSIS 44.In dlfcn.h 45.Ft "void *" 46.Fn dlopen "const char *path" "int mode" 47.Ft "int" 48.Fn dlclose "void *handle" 49.Ft "void *" 50.Fn dlsym "void *handle" "const char *symbol" 51.Ft "int" 52.Fn dladdr "const void *addr" "Dl_info *info" 53.Ft "int" 54.Fn dlctl "void *handle" "int cmd" "void *data" 55.Ft "char *" 56.Fn dlerror "void" 57.Sh DESCRIPTION 58These functions provide an interface to the run-time linker 59.Xr ld.so 1 . 60They allow new shared objects to be loaded into a process's address space 61under program control. 62.Pp 63The 64.Fn dlopen 65function takes the name of a shared object as its first argument. 66The shared object is mapped into the address space, relocated, and its external 67references are resolved in the same way as is done with the implicitly loaded 68shared libraries at program startup. 69.Pp 70The 71.Fa path 72parameter can be specified as either an absolute pathname to a shared library 73or just the name of the shared library itself. 74When an absolute pathname is specified, 75only the path provided will be searched for the shared library. 76When just a shared library is specified, 77the same paths will be searched that are used for 78.Dq intrinsic 79shared library searches. 80.Pp 81Shared libraries take the following form: 82.Pp 83.Dl lib<name>.so[.xx[.yy]] 84.Pp 85When a shared library is specified without a version or with a partial version, 86the same library search rules apply that are used for 87.Dq intrinsic 88shared library searches. 89A null pointer supplied for 90.Fa path 91will return a special 92.Fa handle 93that behaves the same as the 94.Dv RTLD_DEFAULT 95special 96.Fa handle . 97.Pp 98The 99.Fa mode 100parameter specifies symbol resolution time and symbol visibility. 101One of the following values may be used to specify symbol resolution time: 102.Bl -tag -width "RTLD_LAZYXX" -offset indent 103.It Sy RTLD_NOW 104Symbols are resolved immediately. 105.It Sy RTLD_LAZY 106Symbols are resolved when they are first referred to. 107This is the default value if resolution time is unspecified. 108.El 109.Pp 110One of the following values may be used to specify symbol visibility: 111.Bl -tag -width "RTLD_GLOBAL" -offset indent 112.It Sy RTLD_GLOBAL 113The object's symbols and the symbols of its dependencies will be visible to 114other objects. 115.It Sy RTLD_LOCAL 116The object's symbols and the symbols of its dependencies will not be visible to 117other objects. 118This is the default value if visibility is unspecified. 119.El 120.Pp 121To specify both resolution time and visibility, bitwise inclusive OR one of 122each of the above values together. 123If an object was opened with RTLD_LOCAL and later opened with RTLD_GLOBAL, 124then it is promoted to RTLD_GLOBAL. 125.Pp 126Additionally, the following flag may be ORed into the mode argument: 127.Bl -tag -width "RTLD_NODELETE" -offset indent 128.It Sy RTLD_NODELETE 129Prevents unload of the loaded object on 130.Fn dlclose . 131.It Sy RTLD_NOLOAD 132Only return valid handle for the object if it is already loaded in 133the process address space, otherwise NULL is returned. 134Other mode flags may be specified, which will be applied for promotion 135for the found object. 136.El 137.Pp 138The main executable's symbols are normally invisible to 139.Fn dlopen 140symbol resolution. 141Those symbols will be visible if linking is done with 142.Xr cc 1 143.Fl rdynamic , 144which is equivalent to 145.Xr ld 1 146.Fl -export-dynamic . 147.Pp 148All shared objects loaded at program startup are globally visible. 149.Pp 150.Fn dlopen 151returns a 152.Fa handle 153to be used in calls to 154.Fn dlclose , 155.Fn dlsym , 156and 157.Fn dlctl . 158If the named shared object has already been loaded by a previous call to 159.Fn dlopen 160and not yet unloaded by 161.Fn dlclose , 162a 163.Fa handle 164referring to the resident copy is returned. 165.Pp 166.Fn dlclose 167unlinks and removes the object referred to by 168.Fa handle 169from the process address space. 170If multiple calls to 171.Fn dlopen 172have been done on this object or the object is a dependency of another object 173then the object is removed when its reference count drops to zero. 174.Fn dlclose 175returns 0 on success and non-zero on failure. 176.Pp 177.Fn dlsym 178searches for a definition of 179.Fa symbol 180in the object designated by 181.Fa handle 182and all shared objects that it depends on. 183The symbol's address is returned. 184If the symbol cannot be resolved, 185.Dv NULL 186is returned. 187.Pp 188.Fn dlsym 189may also be called with special 190.Fa handles . 191.Fn dlsym 192respects symbol visibility as specified by the 193.Fn dlopen 194.Fa mode 195parameter. 196However, the symbols of an object's dependencies are always visible to it. 197The following special 198.Fa handles 199may be used with 200.Fn dlsym : 201.Bl -tag -width "RTLD_DEFAULTXX" -offset indent 202.It Sy NULL 203Interpreted as a reference to the executable or shared object 204from which the call is being made. 205Thus an object can reference its own symbols and the symbols of its 206dependencies without calling 207.Fn dlopen . 208.It Sy RTLD_DEFAULT 209All the visible shared objects and the executable will be searched 210in the order they were loaded. 211.It Sy RTLD_NEXT 212The search for 213.Fa symbol 214is limited to the visible shared objects which were loaded 215after the one issuing the call to 216.Fn dlsym . 217Thus, if 218.Fn dlsym 219is called from the main program, all the visible shared libraries are searched. 220If it is called from a shared library, all subsequently visible shared 221libraries are searched. 222.It Sy RTLD_SELF 223The search for 224.Fa symbol 225is limited to the shared object issuing the call to 226.Fn dlsym 227and those shared objects which were loaded after it that are visible. 228.El 229.Pp 230.Fn dladdr 231queries the dynamic linker for information about the shared object 232containing the address 233.Fa addr . 234The information is returned in the structure specified by 235.Fa info . 236The structure contains at least the following members: 237.Bl -tag -width "XXXconst char *dli_fname" 238.It Li "const char *dli_fname" 239The pathname of the shared object containing the address 240.Fa addr . 241.It Li "void *dli_fbase" 242The base address at which the shared object is mapped into the 243address space of the calling process. 244.It Li "const char *dli_sname" 245The name of the nearest run-time symbol with an address less than or 246equal to 247.Fa addr . 248.Pp 249If no symbol with a suitable address is found, both this field and 250.Va dli_saddr 251are set to 252.Dv NULL . 253.It Li "void *dli_saddr" 254The address of the symbol returned in 255.Va dli_sname . 256.El 257.Pp 258If a mapped shared object containing 259.Fa addr 260cannot be found, 261.Fn dladdr 262returns 0. 263In that case, a message detailing the failure can be retrieved by 264calling 265.Fn dlerror . 266On success, a non-zero value is returned. 267Note: both strings pointed at by 268.Va dli_fname 269and 270.Va dli_sname 271reside in memory private to the run-time linker module and should not 272be modified by the caller. 273.Pp 274In dynamically linked programs, the address of a global function will 275point to its program linkage table entry, rather than to the entry 276point of the function itself. 277This causes most global functions to appear to be defined within the 278main executable, rather than in the shared libraries where the actual 279code resides. 280.Pp 281.Fn dlctl 282provides an interface similar to 283.Xr ioctl 2 284to control several aspects of the run-time linker's operation. 285This interface is currently under development. 286.Pp 287.Fn dlerror 288returns a character string representing the most recent error that has 289occurred while processing one of the other functions described here. 290If no dynamic linking errors have occurred since the last invocation of 291.Fn dlerror , 292.Fn dlerror 293returns 294.Dv NULL . 295Thus, invoking 296.Fn dlerror 297a second time, immediately following a prior invocation, will result in 298.Dv NULL 299being returned. 300.Sh SEE ALSO 301.Xr ld 1 , 302.Xr ld.so 1 , 303.Xr elf 5 304.Sh STANDARDS 305The 306.Fn dladdr , 307.Fn dlclose , 308.Fn dlerror , 309.Fn dlopen , 310and 311.Fn dlsym 312functions conform to 313.St -p1003.1-2024 . 314.Sh HISTORY 315Some of the 316.Nm dl* 317functions first appeared in SunOS 4. 318.Sh CAVEATS 319Loading untrustworthy libraries into the process's address space with 320.Nm dlopen 321is very dangerous because system-dependent initialization steps occur 322including the calling of constructor functions, even if the library 323is otherwise unused. 324