Runtime Linker

Dynamic applications consist of one or more dynamic objects. The dynamic application is typically a dynamic executable and associated dynamic object dependencies. As part of the initialization of a dynamic application, the runtime linker completes the binding of the application to its dynamic object dependencies.

In addition to initializing an application, the runtime linker provides services that enable the application to extend its address space by adding dynamic objects and binding to symbols within them.

The runtime linker performs the following functions:

• Analyzes the executable's dynamic information section and determines which dynamic libraries are required.

• Locates and loads the required dynamic libraries, and analyzes their dynamic information sections to determine whether additional dynamic library dependencies are required.

• Performs the necessary relocations to bind dynamic libraries in preparation for actor execution (after all dynamic libraries are located and loaded).

• Calls any initialization functions provided by the dynamic libraries. The initialization functions are called in the reverse order of the topologically sorted dependencies. Should cyclical dependencies exist, the initialization functions are called using the sorted order with the cycle removed.

• Passes control to the application.

• Calls all finalization functions on deletion of dynamic objects from the actor. The finalization functions are called in the order of the topologically sorted dependencies.

• Acquires additional dynamic objects with dlopen() and binds to symbols within these objects using dlsym(), if required by the application.

The runtime linker uses a prescribed search path for locating the dynamic dependencies of an object. The default search paths are the runpath recorded in the object, proceeded by /usr/lib. The runpath is specified when the dynamic object is constructed using the -rpath option of the linker. The environment variable LD_LIBRARY_PATH can be used to indicate directories that are to be searched ahead of the default directories.

The runtime linker requires a file system to load dynamic objects. This file system can be on a host and can be accessed through NFS from the target. In embedded systems without a network connection, a bank of the system image can be used. For example, /image/sys_bank.

Environment Variables

The following environment variables are used by the runtime linker:

• LD_LIBRARY_PATH specifies a colon-separated list of directories that are to be searched ahead of the default directories defined previously. The colon-separated list is used to enhance the search path that the runtime linker uses to locate dynamic and shared libraries.

• LD_PRELOAD provides a dynamic object name that is linked after the program is loaded but before any other dynamic objects that the program references.

• LD_DEBUG is a column-separated list of tokens for debugging the runtime linking of an application. Each token is associated with a set of traces that are displayed during runtime linking. The supported tokens are: file-ops, reloc, symbol-resolution, malloc, segment-alloc, dependency, misc, linking, dynamic-map-op, group, and error. Wildcard substitutions can also be used, for example, s* matches both symbol-resolution and segment-alloc. Using just the wildcard (*) matches all traces.

Supported Features

• Immediate binding:

  The runtime linker performs both data reference and function reference relocations during process initialization (before transferring control to the application). This behavior is equivalent to the LD_BIND_NOW behavior in the Solaris operating environment (lazy binding is not supported).

• No version checking:

  The runtime linker does not perform version dependency checking. When looking for a library, the runtime linker looks for a file name that matches the library name exactly. This behavior is equivalent to the LD_NOVERSION behavior in the Solaris operating environment.

• Weak symbols and aliases:

  During symbol resolution, weak symbols are silently overridden by any global definition with the same name. Weak symbols can be defined alone or as aliases to global symbols. Weak symbols are defined with pragma definitions.

• Call debug:

  The runtime linker obtains debug information from the dynamic libary, thereby enabling you to debug the dynamic library.