Runtime Linking Programming Interface

Dependencies specified during the link-edit of an application are processed by the runtime linker during process initialization. In addition to this mechanism, the application can extend its address space during its execution by binding to additional objects. The application effectively uses the same services of the runtime linker that are used to process the applications standard dependencies.

Delayed object binding has several advantages.

  • By processing an object when the object is required rather than during the initialization of an application, startup time can be greatly reduced. If the services provided by an object are not needed during a particular run of the application, the object is not required. This scenario can occur for objects that provide help or debugging information.

  • The application can choose between several different objects, depending on the exact services required, such as for a networking protocol.

  • Any objects added to the process address space during execution can be freed after use.

An application can use the following typical scenario to access an additional shared object.

  • A shared object is located and added to the address space of a running application using dlopen(3C). Any dependencies of this shared object are located and added at this time.

  • The added shared object and its dependencies are relocated. Any initialization sections within these objects are called.

  • The application locates symbols within the added objects using dlsym(3C). The application can then reference the data or call the functions defined by these new symbols.

  • After the application has finished with the objects, the address space can be freed using dlclose(3C). Any termination sections that exist within the objects that are being freed are called at this time.

  • Any error conditions that occur as a result of using the runtime linker interface routines can be displayed using dlerror(3C).

The services of the runtime linker are defined in the header file dlfcn.h and are made available to an application by the shared object libc.so.1. In the following example, the file main.c can make reference to any of the dlopen(3C) family of routines, and the application prog can bind to these routines at runtime.

$ cc -o prog main.c

Note:

In previous releases of the Oracle Solaris OS, the dynamic linking interfaces were made available by the shared object libdl.so.1. libdl.so.1 remains available to support any existing dependencies. However, the dynamic linking interfaces offered by libdl.so.1 are now available from libc.so.1. Linking with -ldl is no longer necessary.