Chapter 1

Introduction to the Solaris Linkers

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.

This manual expands the following areas:

Link-Editor: The link-editor, ld(1), concatenates and interprets data from 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 the cc(1) man page).
Runtime Linker: The runtime linker, ld.so.1(1), processes dynamic executables and shared objects at runtime, and binds them to create a runnable process.
Shared Objects: Shared objects (sometimes referred to as Shared Libraries) are one form of output from the link-edit phase. 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 that it produces is one of four basic types:

Relocatable object - A concatenation of input relocatable objects that 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 runnable process. A dynamic executable might still need symbolic references bound at runtime, and can 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 can 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 runnable 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 enable the runtime linker to load, relocate, and complete the binding process.

During process execution the facilities of the runtime linker are 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 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 runnable process. Dynamic executables are the default output file generated by the link-editor.

Shared objects provide the key building block to a dynamically linked system. 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 runnable process. Because shared objects can be used by many applications, aspects of their construction directly affect shareability, versioning, and performance.

You can 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 runnable 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 runnable process. Dynamic linking enables 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. Dynamic linking is a crucial factor in providing an application binary interface (ABI), and is the preferred compilation method for Solaris applications.

Application Binary Interfaces

Binary interfaces between system and application components are defined to enable the asynchronous evolution of these facilities. The Solaris linkers operate upon these interfaces to assemble applications for execution. Although all components handled by the Solaris linkers have binary interfaces, the whole set of interfaces provided by the system is referred to as the Solaris ABI.

The Solaris ABI is a technological descendent for work on ABIs that started with the System V Application Binary Interface and the successor work performed by SPARC™ International for SPARC processors called the SPARC® Compliance Definition (SCD).

32-Bit and 64-Bit Environments

The link-editors operate on 32-bit objects, and on SPARCV9 systems are also capable of operating on 64-bit objects. On SPARC systems, the 64-bit link-editor (ld(1)) is capable of generating 32-bit objects and the 32-bit link-editor is capable of generating 64-bit objects. In the latter case, the size of the generated object, not including the .bss, is restricted to 2 Gbytes.

No command-line option is required to distinguish a 32-bit or 64-bit link-edit. The link-editor uses the ELF class of the first input relocatable object file it sees on the command-line to govern the mode in which it will operate. Specialized link-edits, such as linking solely from a mapfile or an archive library, are uninfluenced by their input files, and will default to a 32-bit mode. In these cases a 64-bit link-edit can be enforced with the -64 option. Intermixing of 32-bit and 64-bit objects is not permitted.

The operations of the link-editors on 32-bit and 64-bit objects is identical. This document typically uses 32-bit examples. Cases where 64-bit processing differs from the 32-bit processing are highlighted.

For more information regarding 64-bit applications, refer to the Solaris 64-bit Developer's Guide.

Environment Variables

The link-editors support a number of environment variables that begin with the characters LD_, for example LD_LIBRARY_PATH. Each environment variable can exist in its generic form, or can be specified with a _32 or _64 suffix, for example LD_LIBRARY_PATH_64. This suffix makes the environment variable specific, respectively, to 32-bit or 64-bit processes and overrides any generic, non-suffixed, version of the environment variable that may be in effect.

Throughout this document any reference to link-editor environment variables will use the generic, non-suffixed, variant. For a list of all supported environment variables refer to the ld(1) and ld.so.1(1) man pages.

Support Tools

The Solaris operating environment also provides several support tools and libraries. These tools provide for the analysis and inspection of these objects and the linking processes. Among these tools are: elfdump(1), nm(1), dump(1), ldd(1), pvs(1), elf(3ELF), and a linker debugging support library. Throughout this document many discussions are augmented with examples of these tools.


	Chapter 1 Introduction to the Solaris Linkers 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. This manual expands the following areas: Link-Editor The link-editor, `ld`(1), concatenates and interprets data from 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 the `cc`(1) man page). Runtime Linker The runtime linker, `ld.so.1`(1), processes dynamic executables and shared objects at runtime, and binds them to create a runnable process. Shared Objects Shared objects (sometimes referred to as Shared Libraries) are one form of output from the link-edit phase. 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 that it produces is one of four basic types: Relocatable object - A concatenation of input relocatable objects that 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 runnable process. A dynamic executable might still need symbolic references bound at runtime, and can 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 can 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 runnable 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 enable the runtime linker to load, relocate, and complete the binding process. During process execution the facilities of the runtime linker are 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 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 runnable process. Dynamic executables are the default output file generated by the link-editor. Shared objects provide the key building block to a dynamically linked system. 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 runnable process. Because shared objects can be used by many applications, aspects of their construction directly affect shareability, versioning, and performance. You can 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 runnable 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 runnable process. Dynamic linking enables 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. Dynamic linking is a crucial factor in providing an application binary interface (ABI), and is the preferred compilation method for Solaris applications. Application Binary Interfaces Binary interfaces between system and application components are defined to enable the asynchronous evolution of these facilities. The Solaris linkers operate upon these interfaces to assemble applications for execution. Although all components handled by the Solaris linkers have binary interfaces, the whole set of interfaces provided by the system is referred to as the Solaris ABI. The Solaris ABI is a technological descendent for work on ABIs that started with the System V Application Binary Interface and the successor work performed by SPARC™ International for SPARC processors called the SPARC® Compliance Definition (SCD). 32-Bit and 64-Bit Environments The link-editors operate on 32-bit objects, and on SPARCV9 systems are also capable of operating on 64-bit objects. On SPARC systems, the 64-bit link-editor (`ld`(1)) is capable of generating 32-bit objects and the 32-bit link-editor is capable of generating 64-bit objects. In the latter case, the size of the generated object, not including the `.bss`, is restricted to 2 Gbytes. No command-line option is required to distinguish a 32-bit or 64-bit link-edit. The link-editor uses the ELF class of the first input relocatable object file it sees on the command-line to govern the mode in which it will operate. Specialized link-edits, such as linking solely from a `mapfile` or an archive library, are uninfluenced by their input files, and will default to a 32-bit mode. In these cases a 64-bit link-edit can be enforced with the `-64` option. Intermixing of 32-bit and 64-bit objects is not permitted. The operations of the link-editors on 32-bit and 64-bit objects is identical. This document typically uses 32-bit examples. Cases where 64-bit processing differs from the 32-bit processing are highlighted. For more information regarding 64-bit applications, refer to the Solaris 64-bit Developer's Guide. Environment Variables The link-editors support a number of environment variables that begin with the characters `LD_`, for example `LD_LIBRARY_PATH`. Each environment variable can exist in its generic form, or can be specified with a `_32` or `_64` suffix, for example `LD_LIBRARY_PATH_64`. This suffix makes the environment variable specific, respectively, to 32-bit or 64-bit processes and overrides any generic, non-suffixed, version of the environment variable that may be in effect. Throughout this document any reference to link-editor environment variables will use the generic, non-suffixed, variant. For a list of all supported environment variables refer to the `ld`(1) and `ld.so.1`(1) man pages. Support Tools The Solaris operating environment also provides several support tools and libraries. These tools provide for the analysis and inspection of these objects and the linking processes. Among these tools are: `elfdump`(1), `nm`(1), `dump`(1), `ldd`(1), `pvs`(1), `elf`(3ELF), and a linker debugging support library. Throughout this document many discussions are augmented with examples of these tools.