HP-UX Reference (11i v3 07/02) - 5 Miscellaneous Topics (vol 9)

d
dld.so(5) dld.so(5)
(Itanium(R)-based System Only)
The fastbind tool can be used to improve the start-up time of programs that use shared libraries (incom-
plete executables). The
fastbind tool performs analysis on the shared library routines and data used to
bind the symbols and stores this information in the executable file. The dynamic loader notices that this
information is available, and it uses this fastbind information to bind the symbols instead of the standard
search method. For more details refer to fastbind(1) and the
+help option to ld(1) or the HP-UX Linker
and Libraries User’s Guide.
Breadth-first Searching
By default, the dynamic loader does breadth-first searching when binding symbols. If the incomplete exe-
cutable was linked with
+compat or if a
shl_load() is being executed, then depth-first searching is
used. (See Depth-first Searching.) Breadth-first searching specifies that the dynamic loader looks for sym-
bols starting with the incomplete executable followed by all loaded shared libraries in a left to right order
until the symbol is found. For example, the incomplete executable is searched followed by all libraries in its
library load list. Then the dependent shared libraries of the first library in the library load list is searched,
followed by the dependent shared libraries of the second library in the list, and so on.
Version Control
Since code from a shared library is mapped at run time from a separate shared library file, modifications to
a shared library may alter the behavior of existing executables. In some cases, this may cause programs to
operate incorrectly.
Library-level Versioning
Users can control versions of their libraries by using a naming convention,
libname.n where n is a
numeral that is incremented with every new release of the library. When using the new naming scheme,
users must specify an internal name for the shared library by using the
+h internal_name option to
ld
when building the shared library. This internal name is recorded in each incomplete executable or shared
library that links with the shared library.
At run time, the loader looks at the library list recorded in the incomplete executable file or shared library.
For each library in the list that was not an internal name, the dynamic loader looks for a
.0 version of the
library (for example,
libname.0) to load. If it does not find this version, it looks for the library name
that is recorded in the list.
Explicit Loading and Binding
The duties of the dynamic loader as described above are all performed automatically, although they can be
controlled somewhat by appropriate options to ld. The dynamic loader can also be accessed programmati-
cally. The routines described under shl_load(3X), dlclose(3C), dlerror(3C), dlget(3C), dlmodinfo(3C),
dlopen(3C), and dlsym(3C) provide a portable interface that allows the programmer to explicitly attach a
shared library to the process at run time, to calculate the addresses of symbols defined within shared
libraries, and to detach the library when done.
Global Symbol Table
The global symbol table mechanism is designed as a performance enhancement option. Enabling this
mechanism causes the creation of a global symbol table which speeds up symbol lookup, by eliminating the
need to scan all loaded libraries in order to find a symbol. This is particularly effective for applications with
large numbers of shared libraries. This mechanism is off by default.
The global symbol table is implemented using a hash table. Under this mechanism, whenever a library is
loaded (either implicitly or by using
dlopen() or shl_load() ), the mechanism hashes the library’s
exports and places them into this table. When a library is unloaded, the mechanism looks up the library’s
exports in the table and removes them.
The hash table does not contain entries for symbols defined by shl_definesym(). User-defined sym-
bols must therefore be handled separately.
Enabling the mechanism causes
dld to use more memory and impacts the performance of the dlo-
pen()
, dlclose() , shl_load() , and shl_unload() API calls.
With the global symbol table, the dynamic loader may need to perform a large number of hashing opera-
tions to locate symbols. Performing this hash function may cost considerable time, especially when symbol
names are very long (C++ programs). To speed up dld, computing hash values can be off-loaded to the
linker.
Use the +gst options, +gst, +gstsize, and +nodynhash, to control the behavior of the global symbol
table hash mechanism. See the ld(1) and chatr(1) commands for information on these options.
120 Hewlett-Packard Company − 3 − HP-UX 11i Version 3: February 2007