Chapter 1 Introduction

Overview

This manual describes the operations of the Solaris link-editor and runtime linker, together with the objects on which they operate. The basic operation of the Solaris linkers involves the combination of objects and the connection of symbolic references from one object to the symbolic definitions within another. This operation is often referred to as binding.

The main areas this manual expands upon are:

Link-Editor

The link-editor, ld(1), concatenates one or more input files (either relocatable objects, shared objects, or archive libraries) to produce one output file (either a relocatable object, an executable application, or a shared object). The link-editor is most commonly invoked as part of the compilation environment (see cc(1)).

Runtime Linker

The runtime linker, ld.so.1(1) [ld.so.1 is a special case of a shared object and therefore allows itself to be versioned. Here a version number of 1 is used, however later releases of Solaris might provide higher version numbers.] , processes dynamic executables and shared objects at runtime, and binds them to create a runable process.

Shared Objects

Shared objects (sometimes referred to as Shared Libraries) are one form of output from the link-edit phase. However, their importance in creating a powerful, flexible runtime environment warrants a section of its own.

Object Files

The Solaris linkers work with files that conform to the executable and linking format (ELF).

These areas, although separable into individual topics, have a great deal of overlap. While explaining each area, this document brings together the connecting principles and designs.

Link-Editing

Link-editing takes a variety of input files, from cc(1), as(1) or ld(1), and concatenates and interprets the data within these input files to form a single output file. Although the link-editor provides numerous options, the output file produced is one of four basic types:

Relocatable object

A concatenation of input relocatable objects, which can be used in subsequent link-edit phases.

Static executable

A concatenation of input relocatable objects that has all symbolic references bound to the executable, and thus represents a ready-to-run process.

Dynamic executable

A concatenation of input relocatable objects that requires intervention by the runtime linker to produce a runable process. Its symbolic references might still need to be bound at runtime, and it might have one or more dependencies in the form of shared objects.

Shared object

A concatenation of input relocatable objects that provides services that might be bound to a dynamic executable at runtime. The shared object might also have dependencies on other shared objects.

These output files, and the key link-editor options used to create them, are shown in Figure 1-1.

Dynamic executables and shared objects, are often referred to jointly as dynamic objects, and are the main focus of this document.

Figure 1-1 Static or Dynamic Link-editing

Runtime Linking

Runtime linking involves the binding of objects, usually generated from one or more previous link-edits, to generate a runable process. During the generation of these objects by the link-editor, the binding requirements are verified and appropriate bookkeeping information is added to each object to allow the runtime linker to map, relocate, and complete the binding process.

During the execution of the process, the facilities of the runtime linker are also made available and can be used to extend the process' address space by adding additional shared objects on demand. The two most common components involved in runtime linking are dynamic executables and shared objects.

Dynamic Executables

Dynamic executables are applications that are executed under the control of a runtime linker. These applications usually have dependencies in the form of shared objects, which are located and bound by the runtime linker to create a runable process. Dynamic executables are the default output file generated by the link-editor.

Shared Objects

Shared objects provide the key building block to a dynamically linked system. Basically, a shared object is similar to a dynamic executable, however shared objects have not yet been assigned a virtual address.

Dynamic executables usually have dependencies on one or more shared objects. That is, the shared object(s) must be bound to the dynamic executable to produce a runable process. Because shared objects can be used by many applications, aspects of their construction directly affect shareability, versioning and performance.

It is useful to distinguish the processing of shared objects by either the link-editor or the runtime linker by referring to the environments in which the shared objects are being used:

compilation environment

Shared objects are processed by the link-editor to generate dynamic executables or other shared objects. The shared objects become dependencies of the output file being generated.

runtime environment

Shared objects are processed by the runtime linker, together with a dynamic executable, to produce a runable process.

Related Topics

Dynamic Linking

Dynamic linking is a term often used to embrace those portions of the link-editing process that generate dynamic executables and shared objects, together with the runtime linking of these objects to generate a runable process. Dynamic linking allows multiple applications to use the code provided by a shared object by enabling the application to bind to the shared object at runtime.

By separating an application from the services of standard libraries, dynamic linking also increases the portability and extensibility of an application. This separation between the interface of a service and its implementation enables the system to evolve while maintaining application stability, and is a crucial factor in providing an application binary interface (ABI). Dynamic linking is the preferred compilation method for Solaris applications.

Application Binary Interfaces

To enable the asynchronous evolution of system and application components, binary interfaces between these facilities are defined. The Solaris linkers operate upon these interfaces to assemble applications for execution. Although all components handled by the Solaris linkers have binary interfaces, one family of such interfaces of particular interest to applications writers is the System V Application Binary Interface.

The System V Application Binary Interface, or ABI, defines a system interface for compiled application programs. Its purpose is to document a standard binary interface for application programs on systems that implement the System V Interface Definition, Third Edition. Solaris provides for the generation and execution of ABI-conforming applications. On SPARC systems, the ABI is contained as a subset of the SPARC\256 Compliance Definition (SCD).

Many of the topics covered in the following chapters are influenced by the ABI. For more detailed information see the appropriate ABI manuals.

Support Tools

Together with the objects mentioned in the previous sections come several support tools and libraries. These tools provide for the analysis and inspection of these objects and the linking processes. Among these tools are: nm(1), dump(1), ldd(1), pvs(1), elf(3E), and a linker debugging support library. Throughout this document many discussions are augmented with examples of these tools use.

New Features

This section gives an overview of new features and/or updates to this document that are available with the Solaris2.6 release:

• Weak symbol references can trigger archive member extraction by using the link-editor -z weakextract option. Extracting all archive members can be achieved using the -z allextract option. See "Archive Processing".

• Shared objects specified as part of a link-edit that are not referenced by the object being built, can be ignored, and hence their dependency recording suppressed, using the -z ignore option. See "Shared Object Processing".

• The link-editor generates the reserved symbols _START_ and _END_ to provide a means of establishing an objects address range. See "Generating the Output Image".

• Changes have been made to the runtime ordering of initialization and finalization code to better accommodate dependency requirements. See "Initialization and Termination Routines".

• Symbol resolution semantics have been expanded for dlopen(3X). See "Symbol Lookup", RTLD_GROUP in "Isolating a Group", and RTLD_PARENT in "Object Hierarchies".

• Symbol lookup semantics have been expanded with a new dlsym(3X) handle RTLD_DEFAULT. See "Obtaining New Symbols".

• Extensions have been made to filter processing that allow more than one filtee to be defined, and provide for forcibly loading filtees. An example of creating a platform specific filter is also provided. See "Shared Objects as Filters".

• Recording additional version dependencies can be achieved using the mapfile file control directive $ADDVERS. See "Binding to Additional Version Definitions".

• A runtime linker audit interface provides support for monitoring and modifying a dynamically linked application from within the process. See "Runtime Linker Auditing Interface".

• A runtime linker debugger interface provides support for monitoring and modifying a dynamically linked application from an external process. See "Runtime Linker Debugger Interface".

• Additional section types are supported. See Table 7-9 for SHN_BEFORE and SHN_AFTER, and see Table 7-12 for SHF_ORDERED and SHF_EXCLUDE.

• A new dynamic section tag, DT_1_FLAGS, is supported. See Table 7-35 for the various flag values.

• A package of demonstration ELF programs is provided. See Chapter 7, Object Files.

• The link-editors now support internationalized messages. All system errors are reported using strerror(3C).