Dlopened modules

It can sometimes be confusing to discuss dynamic linking, because the term is used to refer to two different concepts:

1. Compiling and linking a program against a shared library, which is resolved automatically at run time by the dynamic linker. In this process, dynamic linking is transparent to the application.
2. The application calling functions such as dlopen(3),(7) which load arbitrary, user-specified modules at runtime. This type of dynamic linking is explicitly controlled by the application.

To mitigate confusion, this manual refers to the second type of dynamic linking as dlopening a module.

The main benefit to dlopening object modules is the ability to access compiled object code to extend your program, rather than using an interpreted language. In fact, dlopen calls are frequently used in language interpreters to provide an efficient way to extend the language.

On most operating systems, dlopened modules must be compiled as PIC. This restriction simplifies the implementation of the dlopen(3) family of functions by avoiding symbol relocation. "True" dlopen implementations, such as the unportable GNU DLD 3 implementation (see section `Introduction' in The DLD Manual), don't have this restriction, as they can perform relocation at runtime.

As of version 1.0, libtool provides only minimal support for dlopened modules, and this support is guaranteed to change and be redesigned in the near future. Because there is not a very high proportion of applications that use dlopening, adding this support to libtool was not deemed a priority for the 1.0 release.

This chapter discusses the preliminary support that libtool offers, and how you as a dlopen application developer might use libtool to generate dlopen-accessible modules. It is important to remember that these are experimental features, and not to rely on them for easy answers to the problems associated with dlopened modules.

Go to the first, previous, next, last section, table of contents.