dld.so.5 (2010 09)

ManualsBrandsHP ManualsSoftwareHP-UX Manpages

dld.so(5)

Itanium(R)-based Systems Only

dld.so(5)

path or embedded path set by the

ld +b command) and the default directory /usr/lib/hpux64

for

64-bit libraries or the default directory

/usr/lib/hpux32

for 32-bit libraries.

For PA-RISC 32-bit compatibility mode libraries (libraries built or linked with

ld +compat), the

dynamic loader only does dynamic path searching for these libraries if they were linked with

-l or -l:

and one of these were speciﬁed:

•

ld +s

• ld +b

• chatr +s enable

There are several ways to specify a dynamic path list :

• By storing a directory path list in the executable (in

rpath) using the +b path_list option to ld.

• By not specifying

ld +b and letting the linker set the

rpath value to a concatenation of the

ld -L

path_list followed by the value of the environment variable

LPATH followed by the 64-bit default

directory

/usr/lib/hpux64

, or the 32-bit default directory /usr/lib/hpux32

• By storing a directory path list in the environment variables

LD_LIBRARY_PATH

and/or

SHLIB_PATH. LD_LIBRARY_PATH

and SHLIB_PATH can contain paths for both 32 and 64 bit

libraries; dld.so will only load appropriate libraries. For compatibility mode shared libraries and exe-

cutables, the directory path list should only be put in the

SHLIB_PATH environment variable.

The path list is a list of one or more path names separated by colons (

:). The dynamic path list works

only for libraries speciﬁed with the

-l or -l: options to ld. However, it can be enabled for libraries

speciﬁed with a full path name using the -l option to chatr (see chatr (1)). If both

+s and +b are used,

their relative order on the command line indicates which path list is searched ﬁrst in compatibility mode.

See the

+help option to ld (1) or the HP-UX Linker and Libraries User’s Guide for more details.

The dynamic loader uses these rules when determining which dynamic path list to use:

• If

ld +noenvvar was speciﬁed and ld +b and ld +compat were not speciﬁed, then the only

dynamic path searching that can be done is to look at the path list in

rpath

followed by the 64-bit

default directory

/usr/lib/hpux64

, or the 32-bit default directory /usr/lib/hpux32.

• If

ld +compat was speciﬁed and ld +b and ld +s were not speciﬁed, no shared library is subject

to dynamic path searching. The link-time location of the library (recorded path) is used.

• If the

ld +compat and ld +b options are not speciﬁed, then the path list in the

LD_LIBRARY_PATH environment variable is searched, followed by the path list in the

SHLIB_PATH

environment variable, followed by the path list in rpath, followed by the 64-bit default directory

/usr/lib/hpux64, or the 32-bit default directory

/usr/lib/hpux32.

• If the

ld +compat, ld +b, and ld +s are speciﬁed, then use the relative ordering of

ld +b and

ld +s to determine if the dynamic loader should use the path list in rpath before

SHLIB_PATH fol-

lowed by library as speciﬁed in the library list. If

ld +b is speciﬁed ﬁrst, use the path list in

rpath

ﬁrst.

The rules change slightly when looking for dependent shared libraries.

• For default mode libraries, the path list in the

LD_LIBRARY_PATH environment variable is searched

ﬁrst, followed by the path list in the SHLIB_PATH environment variable, followed by the value in the

parent shared library’s rpath, followed by the 64-bit default directory /usr/lib/hpux64

, or the

32-bit default directory

/usr/lib/hpux32. The ancestors of a parent shared library may contain a

path list in rpath, but this is ignored when searching for dependent shared libraries of this parent.

Only the parent’s rpath is used.

• For compatibility mode libraries, the search is the same as for parent shared libraries, except

rpath

can be passed from parent shared libraries to child dependent shared libraries to that child’s depen-

dents, and so on.

Binding

The dynamic loader also resolves symbolic references between the executable and libraries. By default,

function calls are trapped via the linkage table and bound on ﬁrst reference. References to data symbols

and other absolute address references cannot be trapped. They are bound on the ﬁrst resolution of a

function call that could potentially reference the object.

2 Hewlett-Packard Company − 2 − HP-UX 11i Version 3: September 2010