Dynamic linking is a term often used to embrace a number of linking concepts. Dynamic linking refers to those portions of the link-editing process that generate dynamic executables and shared objects. Dynamic linking also refers to 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 binding the application 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 OS applications.
Binary interfaces between system and application components are defined to enable the asynchronous evolution of these facilities. The Solaris OS link editors operate upon these interfaces to assemble applications for execution. Although all components handled by the Solaris OS link editors 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 ABI's that started with the System V Application Binary Interface. This work evolved with additions performed by SPARC International, Inc.® for SPARC processors, called the SPARC Compliance Definition (SCD).
The link-editor is provided as a 32–bit application and a 64–bit application. Each link-editor can operate on 32–bit objects and 64–bit objects. On systems that are running a 64–bit environment, both versions of the link-editor can be executed. On systems that are running a 32–bit environment, only the 32–bit version of the link-editor can be executed. For more details see The 32–bit link-editor and 64–bit link-editor.
The runtime linker is provided as a 32–bit object and a 64–bit object. The 32–bit object is used to execute 32–bit processes, and the 64–bit object is used to execute 64–bit processes.
The operations of the link-editors on 32–bit objects and 64–bit objects are identical. This document typically uses 32–bit examples. Cases where 64–bit processing differs from the 32–bit processing are highlighted.
For more information on 64–bit applications, refer to the Solaris 64-bit Developer’s Guide.
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. This suffix also overrides any generic, non-suffixed, version of the environment variable that might be in effect.
Prior to the Solaris 10 release, the link-editors ignored environment variables that were specified without a value. Therefore, in the following example, the generic environment variable setting, /opt/lib, would have been used to search for the dependencies of the 32–bit application prog.
$ LD_LIBRARY_PATH=/opt/lib LD_LIBRARY_PATH_32= prog
With the Solaris 10 release, environment variables specified without a value, that have a _32 or _64 suffix, are processed. These environment variables effectively cancel any associated generic environment variable setting. Thus in the previous example, /opt/lib will not be used to search for the dependencies of the 32–bit application prog.
The Solaris OS also provides several support tools and libraries. These tools provide for the analysis and inspection of these objects and the linking processes. These tools include elfdump(1), lari(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.