HP-UX Reference (11i v1 00/12) - 3 Library Functions A-M (vol 6)

ManualsBrandsHP ManualsSoftwareHP-UX Reference Manuals

191

192

193

194

195

196

197

198

199

200

__________________________________________________________________________________________________________________________________________________________________________________________________

STANDARD Printed by: Nora Chuang [nchuang] STANDARD

/build/1111/BRICK/man3/!!!intro.3c

________________________________________________________________

___ ___

dlopen(3C) dlopen(3C)

If a ﬁle is speciﬁed in multiple dlopen invocations, mode is interpreted at each invocation. Note, however,

that once RTLD_NOW has been speciﬁed, 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 speciﬁed, the object will maintain the RTLD_GLOBAL status regardless of

any previous or future speciﬁcation of RTLD_LOCAL , so long as the object remains in the address space

(see dlclose(3C)).

Symbols introduced into a program through calls to dlopen may be used in relocation activities. Symbols

so introduced may duplicate symbols already deﬁned by the program or previous dlopen operations. To

resolve the ambiguities such a situation might present, the resolution of a symbol reference to a symbol

deﬁnition is based on a symbol resolution order. Two such resolution orders are deﬁned: load and depen-

dency ordering. Load order establishes an ordering among symbol deﬁnitions using the temporal order in

which the objects containing the deﬁnitions were loaded, such that the deﬁnition ﬁrst loaded has priority

over deﬁnitions added later. Load ordering is used in relocation processing. Dependency ordering uses a

‘‘breadth-ﬁrst’’ order starting with a given object, then all of its dependencies, then any dependents of

those, iterating until all dependencies are satisﬁed. With the exception of the global symbol object obtained

via a dlopen operation on a ﬁle 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 ﬁrst made accessible via

dlopen, it and its dependent objects are added in dependency

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 speciﬁed in (for example) C source code as having extern linkage. For

a.out’s, only a subset of

externally visible symbols are typically exported: speciﬁcally 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)).

MULTITHREAD USAGE

This routine is thread-safe.

RETURN VALUE

If ﬁle cannot be found, cannot be opened for reading, is not a shared object, or if an error occurs during the

process of loading ﬁle or relocating its symbolic references,

dlopen returns NULL. More detailed diagnos-

tic information is availablethrough dlerror.

WARNINGS

In 64-bit mode, the environment variable LD_LIBRARY_PATH

and SHLIB_PATH should contain a

colon-separated list of directories, in the same format as the

PATH variable (see sh(1)).

LD_LIBRARY_PATH and SHLIB_PATH will be ignored if the process’ real user id is different from its

effective user id or its real group id is different from its effective group id (see exec(2)).

In 64-bit mode, with the +compat option speciﬁed, LD_LIBRARY_PATH and +b embedded path will be

ignored while searching for dependent libraries.

Use caution when building shared libraries with external library dependencies. Any library that contains

Thread Local Storage (TLS) should not be used as a dependency. If a dependent library contains TLS, and

it is not loaded during program startup (that is, not linked against the executable), the dynamic loader fails

to perform the operation.