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

ManualsBrandsHP ManualsSoftwareHP-UX Reference Manuals

271

272

273

274

275

276

277

278

279

280

dlopen_pa(3C) dlopen_pa(3C)

(For PA-RISC Systems)

Subsequently, 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 speciﬁed 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

speciﬁed 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 deﬁned 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 deﬁnition is based on a symbol resolution order. Two such resolution orders are deﬁned:

load and dependency 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. Depen-

dency 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 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 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.

Note: The 32-bit dynamic loader dld.sl serializes the loading and unloading of shared libraries in mul-

tithreaded applications using a pthread mutex lock. See the HP-UX Linker and Libraries Online User

Guide for more information.

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

diagnostic information is available through 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.