HP-UX Linker and Libraries User's Guide

The symbol resolution order is:
a.out --> libA.sl--> libC.sl --> libD.sl --> libB.sl
Loading Shared Libraries with 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 (e.g. 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.
Using Profile-Based Optimization on Shared Libraries
You can perform profile-based optimization on your shared libraries to improve their performance.
See “Profile-Based Optimization (Itanium)” (page 217) for more information.
Exporting Only the Required Symbols
Normally, all global variables and procedure definitions are exported from a shared library. In
other words, any procedure or variable defined in a shared library is made visible to any code
that uses this library. In addition, the compilers generate "internal" symbols that are exported. You
may be surprised to find that a shared library exports many more symbols than necessary for code
that uses the library. These extra symbols add to the size of the library's symbol table and can
even degrade performance (since the dynamic loader has to search a larger-than-necessary number
of symbols). One possible way to improve shared library performance is to export only those
symbols that need exporting from a library. To control which symbols are exported, use either the
+e or the -h option to the ld command. When +e options are specified, the linker exports only
those symbols specified by +e options. The -h option causes the linker to hide the specified
symbols. For details on using these options, see “Hiding Symbols with -h” (page 39) and “Exporting
Symbols with +e” (page 37). As an example, suppose you created a shared library that defines
the procedures init_prog and quit_prog and the global variable prog_state. To ensure that only
these symbols are exported from the library, specify these options when creating the library: `
+e init_prog +e quit_prog +e prog_state
If you have to export many symbols, you may find it convenient to use the -c file option, which
allows you to specify linker options in file. For instance, you canspecify the above options in a file
named export_opts as:
+e init_prog
+e quit_prog
+e prog_state
Then you must specify the following option on the linker command line: -c export_opts For
details on the -c option, see“Passing Linker Options in a file with -c” (page 44) .
Placing Frequently-Called Routines Together
When the linker creates a shared library, it places the object modules into the library in the order
in which they are specified on the linker command line. The order in which the modules appear
can greatly affect performance. For instance, consider the following modules:
Calls routines in c.o heavily, and its routines are called frequently by c.o.a.o
A huge module, but contains only error routines that are seldom called.b.o
Contains routines that are called frequently by a.o, and calls routines in a.o frequently.c.o
106 Creating and Using Libraries