Go to main content

Oracle® Solaris 11.3 Linkers and Libraries Guide

Exit Print View

Updated: March 2018
Chapter 3

Runtime Linker

As part of the initialization and execution of an executable, an interpreter is called to complete the binding of the application to its dependencies. In the Oracle Solaris OS, this interpreter is referred to as the runtime linker.

During the link-editing of an executable, a special .interp section, together with an associated program header, are created. This section contains a path name specifying the program's interpreter. The default name supplied by the link-editor is the name of the runtime linker: /usr/lib/ld.so.1 for a 32-bit executable and /usr/lib/64/ld.so.1 for a 64-bit executable.

Note -  ld.so.1 is a special case of a shared object. Here, a version number of 1 is used. However, later Oracle Solaris OS releases might provide higher version numbers.

During the process of executing a dynamic object, the kernel loads the file and reads the program header information. See Program Header. From this information, the kernel locates the name of the required interpreter. The kernel loads, and transfers control to this interpreter, passing sufficient information to enable the interpreter to continue executing the application.

In addition to initializing an application, the runtime linker provides services that enable the application to extend its address space. This process involves loading additional objects and binding to symbols provided by these objects.

The runtime linker performs the following actions.

  • Analyzes the executable's dynamic information section (.dynamic) and determines what dependencies are required.

  • Locates and loads these dependencies, analyzing their dynamic information sections to determine if any additional dependencies are required.

  • Performs any necessary relocations to bind these objects in preparation for process execution.

  • Calls any initialization functions provided by the dependencies.

  • Passes control to the application.

  • Can be called upon during the application's execution, to perform any delayed function binding.

  • Can be called upon by the application to acquire additional objects with dlopen(3C), and bind to symbols within these objects with dlsym(3C).