JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Linker and Libraries Guide
search filter icon
search icon

Document Information


1.  Introduction to the Oracle Solaris Link Editors

2.  Link-Editor

3.  Runtime Linker

Shared Object Dependencies

Locating Shared Object Dependencies

Directories Searched by the Runtime Linker

Configuring the Default Search Paths

Dynamic String Tokens

Relocation Processing

Relocation Symbol Lookup

Default Symbol Lookup

Runtime Interposition

When Relocations Are Performed

Relocation Errors

Loading Additional Objects

Lazy Loading of Dynamic Dependencies

Providing an Alternative to dlopen()

Initialization and Termination Routines

Initialization and Termination Order


Runtime Linking Programming Interface

Loading Additional Objects

Relocation Processing

Symbol Lookup

Default Symbol Lookup Model

Defining a Global Object

Isolating a Group

Object Hierarchies

Obtaining New Symbols

Testing for Functionality

Using Interposition

Debugging Aids

Debugging Facility

Debugger Module

4.  Shared Objects

5.  Application Binary Interfaces and Versioning

6.  Support Interfaces

7.  Object File Format

8.  Thread-Local Storage

9.  Mapfiles

A.  Link-Editor Quick Reference

B.  Versioning Quick Reference

C.  Establishing Dependencies with Dynamic String Tokens

D.  Direct Bindings

E.  System V Release 4 (Version 1) Mapfiles

F.  Linker and Libraries Updates and New Features


Loading Additional Objects

The runtime linker provides an additional level of flexibility by enabling you to introduce new objects during process initialization by using the environment variable LD_PRELOAD. This environment variable can be initialized to a shared object or relocatable object file name, or a string of file names separated by white space. These objects are loaded after the dynamic executable and before any dependencies. These objects are assigned world search scope, and global symbol visibility.

In the following example, the dynamic executable prog is loaded, followed by the shared object The dependencies defined within prog are then loaded.

$ LD_PRELOAD=./ prog

The order in which these objects are processed can be displayed using ldd(1).

$ ldd -e LD_PRELOAD=./ prog
        ./ => ./ =>     /lib/

In the following example, the preloading is a little more complex and time consuming.

$ LD_PRELOAD="./foo.o ./bar.o" prog

The runtime linker first link-edits the relocatable objects foo.o and bar.o to generate a shared object that is maintained in memory. This memory image is then inserted between the dynamic executable and its dependencies in the same manner as the shared object was preloaded in the previous example. Again, the order in which these objects are processed can be displayed with ldd(1).

$ ldd -e LD_PRELOAD="./foo.o ./bar.o" ldd prog
        ./foo.o =>       ./foo.o
        ./bar.o =>       ./bar.o =>     /lib/

These mechanisms of inserting an object after a dynamic executable provide for interposition. You can use these mechanisms to experiment with a new implementation of a function that resides in a standard shared object. If you preload an object containing this function, the object interposes on the original. Thus, the original functionality can be completely hidden with the new preloaded version.

Another use of preloading is to augment a function that resides in a standard shared object. The interposition of the new symbol on the original symbol enables the new function to carry out additional processing. The new function can also call through to the original function. This mechanism typically obtains the original symbol's address using dlsym(3C) with the special handle RTLD_NEXT.