HP-UX Linker and Libraries User's Guide

Generally, the linker needs to scan through all shared libraries on a link line in order to determine
all the unsats, even in incremental links. This process may slow down incremental links. The
incremental linker does not scan shared libraries and leaves detection of shared library unsats to
the dynamic loader.
It is not recommended that you use the incremental linker to create final production modules.
Because it reserves additional padding space, modules created by the incremental linker are
considerably larger than those created in regular links.
NOTE: Any program that modifies an executable (for example, strip strip(1)), may affect the
ability of ld to perform an incremental link. When this happens, the incremental linker issues a
message and performs an initial incremental link. Third-party tools that work on object files may
have unexpected results on modules produced by the incremental linker.
Reusing Compiled Object Files (PA-RISC)
You can improve compile time performance by using a feature that reuses compiled object files
resulting from intermediate object code (I-SOM) generation, incrementally recompiling only those
intermediate object code files changed since the prior build. Using the +Oreusedir=dir option,
with C, C++, or the linker, enables this feature. The default behavior is no reuse of object files.
The +Oreusedir=dir option specifies a directory where the linker can save object files created
from intermediate object files when using +O4 or profile- based optimization. When you compile
with +I, +P or +O4, the compiler generates intermediate code in the object file. Otherwise, the
compiler generates regular object code in the object file. When you link, the linker first compiles
the intermediate object code to regular object code, then links the object code. With this option
you can reduce link time on subsequent links by avoiding recompiling intermediate object files that
have already been compiled to regular object code and have not changed.
The dir argument specifies a directory for the reuse repository, where the linker can save object
files created from intermediate object files. The dir argument can be an absolute path name or
relative to the directory in which the linker was invoked. If pathname does not exist, the reuse
mechanism creates a directory with that pathname. If dir exists and is readable, the mechanism
reuses the object files deposited there. If dir exists and is writable, the mechanism stores the object
files for reuse there whenever an I-SOM is compiled to a regular object file.
The reuse repository can reside on a short file name filesystem, where file names are truncated to
14 characters. You can move or copy the reuse repository to another location, including to another
filesystem, and reuse the object file from the new location by compiling with the new dir argument
of +Oreusedir. Moving the repository from a long file name filesystem to a short file name
filesystem forces recompilation of any object file whose full names are longer than 14 characters.
Moving the repository from a short file name filesystem to a long file name filesystem forces a
similar recompilation of any object file whose full names are longer than 14 characters.
When you do change a source file or command line options and recompile, a new intermediate
object file is created and compiled to regular object code in the specified directory. The reuse
mechanism does not remove the previous object file in the directory. You should periodically remove
this directory since old object files cannot be reused and are not automatically removed. You can
also delete an object file in the reuse repository to force it to be recompiled from an I- SOM.
The reuse mechanism does not rebuild an object file when the flow.data file changes. You must
delete those object files stored in the reuse depository if the profile changes significantly enough
to degrade the runtime performance of your code.
Improving Performance with the 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.
220 Improving Your Application Performance