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 Oracle Solaris applications.
Binary interfaces between system and application components are defined to enable the asynchronous evolution of these facilities. The Oracle Solaris link-editor and runtime linker operate upon these interfaces to assemble applications for execution. Although all components handled by the Oracle Solaris link-editor and runtime linker have binary interfaces, the whole set of interfaces provided by the system is referred to as the Oracle Solaris ABI.
The Oracle 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.
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-editor and runtime linker 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 Oracle Solaris 64-bit Developer’s Guide.
The link-editor and runtime linker 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-editor and runtime linker 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
Beginning 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 Oracle 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.