HP UX Software Transition Kit (STK) manual Using Profile-Based Optimization on Shared Libraries

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 -hoption to the ld command. When +e options are specified, the linker exports only those symbols specified by +e options. The -hoption 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 -cfile 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 -coption, 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:

a.o Calls routines in c.o heavily, and its routines are called frequently by c.o. b.o A huge module, but contains only error routines that are seldom called.

c.o Contains routines that are called frequently by a.o, and calls routines in a.o frequently.

106 Creating and Using Libraries