18.4 dlpreopen Loading
On machines which do not have any facility for shared libraries or
dynamic modules, libltdl allows an application to
This feature is extremely useful for debugging, allowing you to make a fully statically linked application from the executable and module objects, without changing any source code to work around the module loading calls. As far as the code outside the libltdl API can tell, these modules really are being loaded dynamically. Driving a symbolic debugger across module boundaries is however much easier when blocks of code aren't moving in and out of memory during execution.
You may have wondered about the purpose of the following line in the dynamic module code in Dependent Libraries:
The reason for redefining the entry point symbol in this way is to
prevent a symbol clash when two or more modules that provide
identically named entry point functions are preloaded into an
executable. It would be otherwise impossible to preload both
`simple-module.c' and `ltdl-module.c', for example, since
each defines the symbol `run'. To allow us to write dynamic
modules that are potentially preloaded,
Supporting this feature in your module loading code is a simple matter of initialising the address lookup table, and `ltdl.h' defines a convenient macro to do exactly that:
Now change the contents of `ltdl-loader.c', and add a call to this macro, so that it looks like this:
Libtool will now be able to fall back to using preloaded static modules if you tell it to, or if the host platform doesn't support native dynamic loading.
If you use `LTDL_SET_PRELOADED_SYMBOLS' in your module loader, you must also specify something to preload to avoid compilation failure due to undefined `lt_preloaded_symbols'. You can name modules on the Libtool link command line using one of `-dlopen' or `-dlpreopen'. This includes support for accessing the symbols of the main executable opened with `lt_dlopen(NULL)'---you can ask Libtool to fall back to preopening the main modules like this:
The `LTDL_SET_PRELOADED_SYMBOLS' macro does not interfere with the normal operation of the code when modules are dynamically loaded, provided you use the `-dlopen' option on the link line. The advantage of referencing the macro by default is that you can recompile the application with or without preloaded module, and all without editing the sources.
If you have no modules to link in by default, you can force Libtool to populate the preload symbol table by using the `-dlopen force' option. This is the option used to preload the symbols of the main executable so that you can subsequently call `lt_dlopen(NULL)'.
Multiple modules can be preloaded, although at the time of writing only Libtool compiled modules can be used. If there is a demand, Libtool will be extended to include native library preloading in a future revision.
To illustrate, I have recompiled the `simple-module.c' module with
The names of the modules that may be subsequently
Note that the current release of Libtool requires that the pseudo-library be present for any libltdl loaded module, even preloaded ones. Once again, if there is sufficient demand, this may be fixed in a future release. Until then, if the pseudo-library was deleted or cannot be found, this will happen:
A side effect of using the `LTDL_SET_PRELOADED_SYMBOLS' macro is that if you subsequently link the application without Libtool, you will get an undefined symbol for the Libtool supplied `lt_preloaded_symbols'. If you need to link in this fashion, you will need to provide a stub that supplies the missing definition. Conversely, you must be careful not to link the stub file when you do link with Libtool, because it will clash with the Libtool generated table it is supposed to replace:
Of course, if you use this stub, and link the application without the benefits of Libtool, you will not be able to use any preloaded modules -- even if you statically link them, since there is no preloaded symbol lookup table in this case.