HP-UX Reference (11i v1 05/09) - 3 Library Functions A-M (vol 6)
d
dlopen(3C) dlopen(3C)
RTLD_GROUP Under this mode, the specified object, and its dependencies, behave as if they were built
with -B group (see ld(1)). Only symbols from objects loaded in the same
dlopen()
invocation are made available for relocation. This ensures that all relocations are satisfied
using symbol definitions from the same
dlopen() invocation.
RTLD_WORLD Under this mode, only symbols from global objects and from the object itself are available
for relocation processing. It does not use symbol definitions from other objects loaded as
part of the dlopen() invocation. This flag has no effect on objects build with
-B group
(see ld(1)).
RTLD_PARENT
Under this mode, symbols from the object that invoked
dlopen() are also made available
for relocation.
The modes
RTLD_GROUP , RTLD_WORLD , and RTLD_PARENT
are presently supported only for 64-bit
applications.
The default modes for
dlopen() are RTLD_WORLD |
RTLD_GROUP . These flags are OR’ed together
when the same object is loaded with different modes.
The following flags do not affect relocation processing but provide other features:
RTLD_NODELETE
Under this mode, the specified object and its dependencies behave as if they were built with
-B nodelete (see ld(1)). An explicit unload using dlclose() or shl_load()
returns success silently without detaching the shared library from the process. Subse-
quently, the shared library handle is valid only for shl_findsym()
. It stays invalid for
dlsym(), dlclose(), and shl_unload() until the next explicit load using
shl_load() or dlclose().
RTLD_NOLOAD
Under this mode, the specified object is not loaded into the process’s address space, but a
valid handle is returned if the object already exists in the process address space. If the
specified object does not already exist, then an error is returned. RTLD_NOLOAD can be
used to query the presence, or for overriding the modes, of an existing object.
Symbols introduced into a program through calls to dlopen() may be used in relocation activities. Sym-
bols so introduced may duplicate symbols already defined by the program or previous dlopen()
opera-
tions. To resolve the ambiguities such a situation might present, the resolution of a symbol reference to a
symbol definition is based on a symbol resolution order. Two such resolution orders are defined: load and
dependency ordering. Load order establishes an ordering among symbol definitions using the temporal
order in which the objects containing the definitions were loaded, such that the definition first loaded has
priority over definitions added later. Load ordering is used in relocation processing. Dependency ordering
uses a "breadth-first" order starting with a given object, then all of its dependencies, then any dependents
of those, iterating until all dependencies are satisfied. With the exception of the global symbol object
obtained via a
dlopen() operation on a file with a value 0, dependency ordering is used by the
dlsym()
function. Load ordering is used in dlsym() operations on the global symbol object.
When an object is first made accessible via dlopen(), it and its dependent objects are added in depen-
dency order. Once all objects are added, relocations are performed using load order. Note that if an object
and its dependencies have been loaded by a previous dlopen() invocation or on startup, the load and
dependency order may yield different resolutions.
The symbols introduced by dlopen() operations and available through dlsym() are those which are
"exported" as symbols of global scope by the object. For shared objects, such symbols are typically those
that were specified in (for example) C source code as having extern linkage. For a.out’s, only a subset of
externally visible symbols are typically exported: specifically those referenced by the shared objects with
which the a.out is linked. The exact set of exported symbols for any shared object or the a.out can be
controlled using the linker (see ld(1)).
PA-RISC 64-bit dlopene()
The dlopen_opts structure has the following members:
struct dlopen_opts {
long flags;
char* text_addr;
char* data_addr;
};
Section 3−−174 Hewlett-Packard Company − 3 − HP-UX 11i Version 1: September 2005