Back: User Module Loaders
Forward: libltdl Loader Management
 
FastBack: Using GNU libltdl
Up: User Module Loaders
FastForward: Advanced GNU Automake Usage
Top: Autoconf, Automake, and Libtool
Contents: Table of Contents
Index: Index
About: About this document

18.5.1 Loader Mechanism


Since Libtool 1.4, libltdl has provided a generalized method for loading modules, which can be extended by the user. libltdl has a default built in list of module loading mechanisms, some of which are peculiar to a given platform, others of which are more general. When the `libltdl' subdirectory of a project is configured, the list is narrowed to include only those mechanisms, or simply loaders, which can work on the host architecture. When `lt_dlopen' is called, the loaders in this list are tried, in order, until the named module has loaded, or all of the loaders in the list have been exhausted. The entries in the final list of loaders each have a unique name, although there may be several candidate loaders for a single name before the list is narrowed. For example, the `dlopen' loader is implemented differently on BeOS and Solaris -- for a single host, there can be only one implementation of any named loader. The name of a module loader is something entirely different to the name of a loaded module, something that should become clearer as you read on.

In addition to the loaders supplied with libltdl, your project can add more loaders of its own. New loaders can be added to the end of the existing list, or immediately before any other particular loader, thus giving you complete control of the relative priorities of all of the active loaders in your project.

In your module loading API, you might even support the dynamic loading of user supplied loaders: that is your users would be able to create dynamic modules which added more loading mechanisms to the existing list of loaders!

Version 1.4 of Libtool has a default list that potentially contains an implementation of the following loaders (assuming all are supported by the host platform):

dlpreopen
If the named module was preloaded, use the preloaded symbol table for subsequent lt_dlsym calls.

dlopen
If the host machine has a native dynamic loader API use that to try and load the module.

dld
If the host machine has GNU dld(44), use that to try and load the module.

Note that loader names with a `dl' prefix are reserved for future use by Libtool, so you should choose something else for your own module names to prevent a name clash with future Libtool releases.



This document was generated by Gary V. Vaughan on February, 8 2006 using texi2html