HP-UX Reference (11i v2 04/09) - 3 Library Functions A-M (vol 6)

d
dlopen_ia(3C) dlopen_ia(3C)
(For Itanium(R)-based Systems)
RTLD_LOCAL The object’s symbols are made available for relocation processing only to objects loaded in
the same dlopen() invocation.
If neither
RTLD_GLOBAL nor RTLD_LOCAL are specified, the default is
RTLD_LOCAL.
If a file is specified in multiple
dlopen() invocations, mode is interpreted at each invocation. Note,
however, that once
RTLD_NOW has been specified, all relocations will have been completed, rendering any
further RTLD_NOW operations redundant and any further
RTLD_LAZY operations irrelevant. Similarly
note that once
RTLD_GLOBAL has been specified, the object will maintain the
RTLD_GLOBAL status
regardless of any previous or future specification of
RTLD_LOCAL, so long as the object remains in the
address space (see dlclose (3C)).
To determine the scope of symbols that are made available for relocation processing of objects loaded in a
dlopen() invocation, the mode parameter can be bitwise or’ed with one of the following values:
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 avail-
able for relocation.
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.
Symbols so introduced may duplicate symbols already defined by the program or previous dlopen()
operations. To resolve the ambiguities such a situation might present, the resolution of a symbol refer-
ence 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. Depen-
dency 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 will typically be
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
HP-UX 11i Version 2: September 2004 − 2 − Hewlett-Packard Company Section 3−−217