HP-UX Reference (11i v1 00/12) - 1 User Commands A-M (vol 1)

__________________________________________________________________________________________________________________________________________________________________________________________________
__________________________________________________________________________________________________________________________________________________________________________________________________
STANDARD Printed by: Nora Chuang [nchuang] STANDARD
/build/1111/BRICK/man1/!!!intro.1
________________________________________________________________
___ ___
l
ld(1) ld(1)
• Changed linker command line, where the linker command line does not match the command line
stored in the output file. (With the exceptions of the verbose and tracing options)
• Any of the padding spaces have been exhausted.
• Modules have been modified by the ld -s or ld -x options or tools (for example, strip(1)). The
incremental linking requires the parts of the output load module which are stripped out with these
options.
• Incompatible incremental linker version, when you run a new version of the incremental linker on an
executable created by an older version.
• New working directory, where the incremental linker performs an initial incremental link if current
directory changes.
• Archive or shared librariesare added/removed to/from the linker command line.
• Objects are added/removed to/from the linker command line.
See the Online Linker and Libraries User’s Guide (ld +help) for more information.
Archive Library Processing
The incremental linker searches an archive library if there are unsatisfied symbols. It extracts all archive
members satisfying unsats and processes them as new object files. If an archive library is modified, the
linker replaces the modifed archive library.
An object file extracted from an archive library in the previous link remains in the output load module even
if all references to symbols defined in the object file have been removed. The linker removes these object
files when it performs the next initial incremental link.
Shared Library Processing
In an initial incremental link, the linker scans shared library symbol tables and resolves unsats the same
way it would in a regular link. In incremental links, the linker does not process shared libraries and their
symbol tables at all and does not report shared library unsats. The dynamic loader detects them at run
time. If any of the shared libraries on the command line was modified, the linker reverts to an initial incre-
mental link.
Performance
Performance of the incremental linker may suffer greatly if you change a high percentage of object files.
The incremental linker may not link small programs much faster, and the relative increase in size of the
executable is greater than that for larger programs.
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.
Do not use the incremental linker to create final production modules. Because it reserves additional pad-
ding space, modules created by the incremental linker are considerably larger than those created in regular
links.
Notes
Any program that modifies an executable (for example, 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 incre-
mental linker.
EXTERNAL INFLUENCES
Environment Variables
The following internationalization variables affect the execution of
ld:
FLOW_DATA
An instrumented executable (see the -I option) writes out the profile data to a database file named
flow.data in the current directory. The name and location of this file can be specified by setting
FLOW_DATA to the desired path name. The profile data is stored in the database file under a look-up
name that is the same as the basename of the executable file specified at run-time. A single flow.data
file can hold profile data for multiple program files.
HP-UX Release 11i: December 2000 − 13 − Section 1−−435
___
___