It can sometimes be confusing to discuss dynamic linking, because the term is used to refer to two different concepts:
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.
On some operating systems, a program symbol must be specially declared
in order to be dynamically resolved with the
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 burger$
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 burger$
Libtool provides special support for dlopening libtool object and
libtool library files, so that their symbols can be resolved even
on platforms without any
Consider the following alternative ways of loading code into your program, in order of increasing "laziness":
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).
"fprintf". The address attribute is a generic pointer to the appropriate object, which is
&fprintfin this example.
-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.
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
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.
The following problems are not solved by using libtool's dlopen support:
dlopen(3)family, which do package-specific tricks when dlopening is unsupported or not available on a given platform.
dlopen(3)family of functions. Some platforms do not even use the same function names (notably HP-UX, with its `shl_load(3)' family).
Each of these limitations will be addressed in GNU DLD 4.(8)
Go to the first, previous, next, last section, table of contents.