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