5 Link-Editor Quick Reference
The following sections provide a simple overview of the most commonly used link-editor scenarios.
See Link Editing With the Link-Editor for an introduction to the kinds of output modules generated by the link-editor.
The examples provided show the link-editor options as supplied to a compiler driver, this being the most common mechanism of invoking the link-editor. In these examples cc(1) is used. See Using a Compiler Driver.
The link-editor places no meaning on the name of any input file. Each file is opened and inspected to determine the type of processing it requires. See Input File Processing.
Shared objects that follow a naming convention of lib
x
.so, and archive libraries that follow a naming convention of lib
x
.a, can be input using the -l option. See Library Naming Conventions. This provides additional flexibility in allowing search paths to be specified using the -L option. See Directories Searched by the Link-Editor.
Over time, the link-editor has added many features that provide for the creation of high quality objects. These features can enable the object to be used efficiently and reliably in various runtime environments. However, to ensure backward compatibility with existing build environments, many of these features are not enabled by default. For example, features such as direct bindings and lazy loading must be explicitly enabled. The link-editor provides the -z guidance option to help simplify the process of selecting which features to apply. When guidance is requested, the link-editor will issue warning guidance messages, suggesting actions that can lead to higher quality objects. Guidance messages might change over time, as new features are added to the link-editor, or as better practices are discovered to generate high qualify objects. See
ld(1).
The link-editor basically operates in one of two modes, static or dynamic.