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

9 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),(6) 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.

As of version 1.2a, libtool provides experimental support for dlopened modules, which does not radically simplify the development of dlopening applications. However, this support is designed to be a portable foundation for generic, higher-level dlopen functions.

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.

9.1 Building modules to dlopen

On some operating systems, a program symbol must be specially declared in order to be dynamically resolved with the dlsym(3) (or equivalent) function.

Libtool provides the `-export-dynamic' link flag (see section 4.2 Link mode), which does this declaration. You need to use this flag if you are linking an application program that dlopens other modules or a libtool library that will also be dlopened.

For example, if we wanted to build a shared library, `libhello', that would later be dlopened by an application, we would add `-export-dynamic' to the other link flags:

burger$ libtool gcc -export-dynamic -o libhello.la foo.lo \
                hello.lo -rpath /usr/local/lib -lm

Another situation where you would use `-export-dynamic' is if symbols from your executable are needed to satisfy unresolved references in a library you want to dlopen. In this case, you should use `-export-dynamic' while linking the executable that calls dlopen:

burger$ libtool gcc -export-dynamic -o hell-dlopener main.o

9.2 Dlpreopening

Libtool provides special support for dlopening libtool object and libtool library files, so that their symbols can be resolved even on platforms without any dlopen(3) and dlsym(3) functions..

Consider the following alternative ways of loading code into your program, in order of increasing "laziness":

  1. Linking against object files that become part of the program executable, whether or not they are referenced. If an object file cannot be found, then the linker refuses to create the executable.
  2. Declaring a static library to the linker, so that it is searched at link time in order to satisfy any undefined references in the above object files. If the static library cannot be found, then the linker refuses to link the executable.
  3. Declaring a shared library to the runtime linker, so that it is searched at runtime in order to satisfy any undefined references in the above files. If the shared library cannot be found, then the dynamic linker aborts the program before it runs.
  4. Dlopening a module, so that the application can resolve its own, dynamically-computed references. If there is an error opening the module, or the module is not found, then the application can recover without crashing.

Libtool emulates `-export-dynamic' on static platforms by linking objects into the program at compile time, and creating data structures that represent the program's symbol table.

In order to use this feature, you must declare the objects you want your application to dlopen by using the `-dlopen' or `-dlpreopen' flags when you link your program (see section 4.2 Link mode).

Structure: dld_symbol name address
The name attribute is a 0-terminated character string of the symbol name, such as "fprintf". The address attribute is a generic pointer to the appropriate object, which is &fprintf in this example.

Variable: dld_symbol * dld_preloaded_symbols
An array of dld_symbol structures, representing all the preloaded symbols linked into the program. The last element has a name of 0.

Variable: int dld_preloaded_symbol_count
The number of elements in dld_preloaded_symbols, if it is sorted in ascending order by name. Otherwise, -1, to indicate that the application needs to sort and count dld_preloaded_symbols itself, or search it linearly.

Some compilers may allow identifiers which are not valid in ANSI C, such as dollar signs. Libtool only recognizes valid ANSI C symbols (an initial ASCII letter or underscore, followed by zero or more ASCII letters, digits, and underscores), so non-ANSI symbols will not appear in dld_preloaded_symbols.

9.3 Finding the correct name to dlopen

After a library has been linked with `-export-dynamic', it can be dlopened. Unfortunately, because of the variation in library names, your package needs to determine the correct file to dlopen.

The most straightforward and flexible implementation is to determine the name at runtime, by finding the installed `.la' file, and searching it for the following lines:

# The name that we can dlopen(3).

If dlname is empty, then the library cannot be dlopened. Otherwise, it gives the dlname of the library. So, if the library was installed as `/usr/local/lib/libhello.la', and the dlname was `libhello.so.3', then `/usr/local/lib/libhello.so.3' should be dlopened.

If your program uses this approach, then it should search the directories listed in the LD_LIBRARY_PATH(7) environment variable, as well as the directory where libraries will eventually be installed. Searching this variable (or equivalent) will guarantee that your program can find its dlopened modules, even before installation, provided you have linked them using libtool.

9.4 Unresolved dlopen issues

The following problems are not solved by using libtool's dlopen support:

Each of these limitations will be addressed in GNU DLD 4.(8)

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