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

d
dld.sl(5) dld.sl(5)
(PA-RISC System Only)
The potential problems are :
• If the library has initializers/terminators, they will be called twice
• you may end up using two different copies of the same data symbol which may cause incorrect
behavior
You can specify multiple libraries as part of the
LD_PRELOAD environment variable. Separate the
libraries by spaces or colons as in
LD_LIBRARY_PATH. (Multi-byte support is not provided as part of
parsing the
LD_PRELOAD library list). You can specify
LD_PRELOAD libraries with absolute paths or
relative paths. The
LD_PRELOAD libraries can also consist of just the library names, in which case the
dynamic loader uses the directory path list in the environment variables
LD_LIBRARY_PATH
and/or
SHLIB_PATH or the embedded path list (if enabled) to search for the libraries.
The dynamic loader does not issue an error or warning message if it cannot find a library specified by
LD_PRELOAD . However, if it does not find a dependent of the
LD_PRELOAD libraries, the dynamic
loader issues the same error message as if the
LD_PRELOAD library is specified in the link line.
The LD_PRELOAD_ONCE Environment Variable
The
LD_PRELOAD_ONCE feature is similar to
LD_PRELOAD except that the dynamic loader, dld.sl,
unsets
LD_PRELOAD_ONCE after reading it, so that any applications invoked by the current application
do not have
LD_PRELOAD_ONCE
set. This is useful in situations where the current application needs cer-
tain libraries preloaded while the child application is adversely affected if these are preloaded (for example,
ksh terminates abnormally if LD_PRELOAD contains /usr/lib/libpthread.1
). The libraries
specified by
LD_PRELOAD_ONCE
are loaded before the ones specified by LD_PRELOAD . The effect on
symbol resolution is that the symbols from libraries specified by
LD_PRELOAD_ONCE
take precedence
over symbols from libraries specified by
LD_PRELOAD .
DIAGNOSTICS
If the dynamic loader is not present, or cannot be invoked by the process for any reason, an error message
is printed to standard error and the process terminates with a non-zero exit code.
These errors fall into two basic categories: errors in attaching a shared library, and errors in binding sym-
bols. The former can occur only at process startup time but the latter can occur at any time during process
execution unless the -B immediate option is used with ld. Possible errors that can occur while attach-
ing a shared library include library not present, library not executable, library corrupt, high water mark too
low, or insufficient room in the address space for the library. Possible errors that can occur while binding
symbols include symbol not found (unresolved external), or library corrupt.
When using the explicit load facilities of the dynamic loader, these types of errors are not considered fatal.
Consult shl_load(3X), dlclose(3C), dlget(3C), dlgetname(3C), dlmodinfo(3C), dlopen(3C), and dlsym(3C) for
more information. On PA-RISC 64-bit systems, to see error messages, use the
dlerror() routine. This
routine will print the last error message recorded by the dynamic loader.
WARNINGS
The startup cost of the dynamic loader is significant, even with deferred binding, and can cause severe per-
formance degradation in processes dominated by startup costs (such as simple ‘‘hello world’’ programs). In
addition, position-independent code is usually slower than normal code, so performance of a program may
be adversely affected by the presence of PIC in shared libraries. However, the advantages of decreased
disk space usage and decreased memory requirements for executables should outweigh these concerns in
most cases.
There are rare cases where the behavior of a program differs when using shared libraries as opposed to
archive libraries. This happens primarily when relying on undocumented and unsupported features of the
compilers, assembler, and linker. See the
+help option to ld(1) or the HP-UX Linker and Libraries User’s
Guide manual for more details.
The library developer is entirely responsible for version control and must be thorough in identifying incom-
patible changes to library interfaces. Otherwise, programs may malfunction unexpectedly with later ver-
sions of the library. There is little an application user can do if version control is not handled properly by
the library developer. The application developer can usually resolve problems by modifying the source code
to use the new interfaces then recompiling and relinking against the new libraries.
By default, most warnings are not reported by the dynamic loader.
On PA-RISC 32-bit systems, if you wish to see all of the messages, set the environment variable
_HP_DLDOPTS to contain one or more options. The following options are supported:
116 Hewlett-Packard Company − 6 − HP-UX 11i Version 3: February 2007