ld(1)

ld(1)

∙Changed linker command line, where the linker command line does not match the command line stored in the output ®le. (With the exceptions of the verbose and tracing options)

∙Any of the padding spaces have been exhausted.

∙Modules have been modi®ed by the ld -sor ld -xoptions 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 libraries are 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 unsatis®ed symbols. It extracts all archive members satisfying unsats and processes them as new object ®les. If an archive library is modi®ed, the linker replaces the modifed archive library.

An object ®le extracted from an archive library in the previous link remains in the output load module even if all references to symbols de®ned in the object ®le have been removed. The linker removes these object ®les 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 modi®ed, the linker reverts to an initial incremental link.

Performance

Performance of the incremental linker may suffer greatly if you change a high percentage of object ®les.

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 ®nal production modules. Because it reserves additional padding space, modules created by the incremental linker are considerably larger than those created in regular links.

Notes

Any program that modi®es 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 ®les may have unexpected results on modules produced by the incremental linker.

EXTERNAL INFLUENCES

Environment Variables

The following internationalization variables affect the execution of ld:

FLOW_DATA

An instrumented executable (see the -Ioption) writes out the pro®le data to a database ®le named ¯ow.data in the current directory. The name and location of this ®le can be speci®ed by setting FLOW_DATA to the desired path name. The pro®le data is stored in the database ®le under a look-up name that is the same as the basename of the executable ®le speci®ed at run-time. A single ¯ow.data ®le can hold pro®le data for multiple program ®les.

HP-UX Release 11i: December 2000

− 13 −

Section 1−435

l