HP-UX Reference (11i v2 04/09) - 5 Miscellaneous Topics (vol 9)

ManualsBrandsHP ManualsSoftwareHP-UX Reference Manuals

101

102

103

104

105

106

107

108

109

110

dld.sl(5) dld.sl(5)

(PA-RISC System Only)

NOTE: If an archive library is already linked-in with the application and we try to load the shared ver-

sion of that library using LD_PRELOAD we will have problems.

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 ﬁnd a library speciﬁed by

LD_PRELOAD. However, if it does not ﬁnd a dependent of the

LD_PRELOAD libraries, the dynamic

loader issues the same error message as if the

LD_PRELOAD library is speciﬁed 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

certain 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 speciﬁed by

LD_PRELOAD_ONCE

are loaded before the ones speciﬁed by LD_PRELOAD. The

effect on symbol resolution is that the symbols from libraries speciﬁed by

LD_PRELOAD_ONCE take pre-

cedence over symbols from libraries speciﬁed 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

symbols. 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 attaching a shared library include library not present, library not executable, library corrupt, high

water mark too low, or insufﬁcient 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 signiﬁcant, even with deferred binding, and can cause severe

performance degradation in processes dominated by startup costs (such as simple ‘‘hello world’’ pro-

grams). 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

incompatible changes to library interfaces. Otherwise, programs may malfunction unexpectedly with

later versions 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.

Section 5−−88 Hewlett-Packard Company − 6 − HP-UX 11i Version 2: September 2004