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