Relocation Symbol Lookup

The runtime linker is responsible for searching for symbols that are required by objects at runtime. Typically, users become familiar with the default search model that is applied to an executable and its dependencies, and to the objects obtained through dlopen(3C). However, more complex flavors of symbol lookup can result because of the symbol attributes of an object, or through specific binding requirements.

Two attributes of an object affect symbol lookup. The first attribute is the requesting object's symbol search scope. The second attribute is the symbol visibility offered by each object within the process.

These attributes can be applied as defaults at the time the object is loaded. These attributes can also be supplied as specific modes to dlopen(3C). In some cases, these attributes can be recorded within the object at the time the object is built.

An object can define a world search scope, and/or a group search scope.

world

The object can search for symbols in any other global object within the process.

group

The object can search for symbols in any object of the same group. The dependency tree created from an object obtained with dlopen(3C), or from an object built using the link-editor's -B group option, forms a unique group.

An object can define that any of the object's exported symbols are globally visible or locally visible.

global

The object's exported symbols can be referenced from any object that has world search scope.

local

The object's exported symbols can be referenced only from other objects that make up the same group.

The runtime symbol search can also be dictated by a symbols visibility. Symbols assigned the STV_SINGLETON visibility are not affected by any symbol search scope. All references to a singleton symbol are bound to the first occurrence of a singleton definition within the process. See ELF Symbol Visibility.

The simplest form of symbol lookup is outlined in the next section Default Symbol Lookup. Typically, symbol attributes are exploited by various forms of dlopen(3C). These scenarios are discussed in Symbol Lookup.

An alternative model for symbol lookup is provided when a dynamic object employs direct bindings. This model directs the runtime linker to search for a symbol directly in the object that provided the symbol at link-edit time. See Direct Bindings.