Linking Terminology

My explanation to all the details of linking process and their terms

Sources

Here are the sources I used to write this post: Chapter 1 Introduction to the Oracle Solaris Link Editors

Static Executables

The creation of static executables has been discouraged for many releases. In fact, 64-bit system archive libraries have never been provided. Because a static executable is built against system archive libraries, the executable contains system implementation details. This self-containment has a number of drawbacks.

• The executable is immune to the benefits of system patches delivered as shared objects. The executable therefore, must be rebuilt to take advantage of many system improvements.

• The ability of the executable to run on future releases can be compromised.

• The duplication of system implementation details negatively affects system performance.

Runtime Linker

At its core, runtime linking binds various pre-compiled components (called objects) to generate a runnable program. These objects are often products of previous link-editing a process performed during compilation to assemble code modules into executable or shared files.

To make runtime linking efficient:

• Bookkeeping information is generated by the link-editor. This data includes details about how different components relate to each other, ensuring that all dependencies are properly accounted for.

• The runtime linker uses this information to:

1. Load the necessary components into memory.

2. Relocate these components to the appropriate memory addresses.

3. Bind the components together to form a functional program.

Runtime linking doesn’t stop at just preparing a program to run. It also plays a dynamic role during the program’s execution:

• It can extend the process’s address space, loading additional components (shared objects) as needed.

• This on-demand linking enhances flexibility, as programs can incorporate external libraries or modules dynamically during their lifetime.

Two key elements in runtime linking are dynamic executables and shared objects.

Dynamic Executables

A dynamic executable is the primary application file that users run. However, dynamic executables often rely on external libraries or shared objects for functionality. Here’s how it works:

1. The runtime linker controls the execution of dynamic executables.

2. At runtime, the linker locates the required shared objects and binds them to the executable, making the application functional.

Default Behavior:

Dynamic executables are the default output generated by the link-editor. This makes them a cornerstone of any dynamically linked system.

Shared Objects

Shared objects are reusable components designed to be loaded by multiple programs. They are similar to dynamic executables but with a key difference:

Shared objects don’t have a fixed virtual address until runtime.

This distinction makes shared objects versatile and efficient, enabling:

• Resource Sharing: Multiple programs can use the same shared object, reducing memory usage and redundancy.

• Modularity: Developers can update shared objects independently of the programs that use them, streamlining maintenance and upgrades.

Dynamic Executables and Shared Object Dependencies

Dynamic executables typically depend on one or more shared objects. For example:

• A graphical application might rely on shared objects for rendering, input handling, and networking.
• At runtime, these shared objects are bound to the executable to produce a complete, runnable process.

This dependency system makes shared objects critical to performance and maintainability:

• Shareability: Shared objects are designed to be used across multiple applications.

• Versioning: Updates to shared objects need careful management to avoid breaking dependent applications.

• Performance: Efficient construction of shared objects reduces overhead during runtime linking.

Shared Object Processing: Compilation vs. Runtime

The way shared objects are processed depends on the context in which they’re used:

1. Compilation Environment

• The link-editor processes shared objects to create either:

• Dynamic executables

• Other shared objects

• These shared objects are embedded as dependencies in the generated output file, ensuring that the runtime linker can locate and bind them during execution.

1. Runtime Environment

• The runtime linker processes shared objects alongside a dynamic executable to produce a runnable process.

• The linker loads shared objects into memory, resolves references, and assigns them a virtual address dynamically.`

Dynamic Linking

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)

Highly-recommend reading

Beginner’s Guide to Linkers

Guide to Object File Linking