|DLOPEN(3)||Library Functions Manual||DLOPEN(3)|
char *path, int
*handle, const char
void *addr, Dl_info
*handle, int cmd,
dlopen() function takes the name of a
shared object as its first argument. The shared object is mapped into the
address space, relocated, and its external references are resolved in the
same way as is done with the implicitly loaded shared libraries at program
The path parameter can be specified as either an absolute pathname to a shared library or just the name of the shared library itself. When an absolute pathname is specified, only the path provided will be searched for the shared library. When just a shared library is specified, the same paths will be searched that are used for “intrinsic” shared library searches.
Shared libraries take the following form:
When a shared library is specified without a version or with a
partial version, the same library search rules apply that are used for
“intrinsic” shared library searches. A null pointer supplied
for path will return a special
handle that behaves the same as the
The mode parameter specifies symbol resolution time and symbol visibility. One of the following values may be used to specify symbol resolution time:
One of the following values may be used to specify symbol visibility:
To specify both resolution time and visibility, bitwise inclusive OR one of each of the above values together. If an object was opened with RTLD_LOCAL and later opened with RTLD_GLOBAL, then it is promoted to RTLD_GLOBAL.
The main executable's symbols are normally invisible to
dlopen() symbol resolution. Those symbols will be
visible if linking is done with gcc(1)
-rdynamic, which is equivalent to
All shared objects loaded at program startup are globally visible.
dlopen() returns a
handle to be used in calls to
dlctl(). If the named shared object has already been
loaded by a previous call to
dlopen() and not yet
handle referring to the resident copy is returned.
dlclose() unlinks and removes the object
referred to by handle from the process address space.
If multiple calls to
dlopen() have been done on this
object or the object is a dependency of another object then the object is
removed when its reference count drops to zero.
dlclose() returns 0 on success and non-zero on
dlsym() searches for a definition of
symbol in the object designated by
handle and all shared objects that it depends on. The
symbol's address is returned. If the symbol cannot be resolved,
NULL is returned.
dlsym() may also be called with special
symbol visibility as specified by the
mode parameter. However, the symbols of an object's
dependencies are always visible to it. The following special
handles may be used with
dlsym(). Thus, if
dlsym() is called from the main program, all the visible shared libraries are searched. If it is called from a shared library, all subsequently visible shared libraries are searched.
dlsym() and those shared objects which were loaded after it that are visible.
dladdr() queries the dynamic linker for
information about the shared object containing the address
addr. The information is returned in the structure
specified by info. The structure contains at least the
const char *dli_fname
const char *dli_sname
If no symbol with a suitable address is found, both this field
and dli_saddr are set to
If a mapped shared object containing addr
cannot be found,
dladdr() returns 0. In that case, a
message detailing the failure can be retrieved by calling
dlerror(). On success, a non-zero value is returned.
Note: both strings pointed at by dli_fname and
dli_sname reside in memory private to the run-time
linker module and should not be modified by the caller.
In dynamically linked programs, the address of a global function will point to its program linkage table entry, rather than to the entry point of the function itself. This causes most global functions to appear to be defined within the main executable, rather than in the shared libraries where the actual code resides.
dlctl() provides an interface similar to
ioctl(2) to control several aspects of the
run-time linker's operation. This interface is currently under
dlerror() returns a character string
representing the most recent error that has occurred while processing one of
the other functions described here. If no dynamic linking errors have
occurred since the last invocation of
dlerror() a second time, immediately
following a prior invocation, will result in
dl*functions first appeared in SunOS 4.
|November 10, 2015||OpenBSD-current|