|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]||[Top]||[Contents]||[Index]||[ ? ]|
When you are writing a program that will load dynamic modules, a major
stumbling block is writing the code to find the modules you wish to
load. If you are worried about portability (which you must be, or you
wouldn’t be reading this book!), you can’t rely on the default search
algorithm of the vendor
dlopen function, since it varies from
implementation to implementation. You can’t even rely on the name of
the module, since the module suffix will vary according to the
conventions of the target host (though you could insist on a particular
suffix for modules you are willing to load).
Unfortunately, this means that you will need to implement your own
searching algorithm and always use an absolute pathname when you call
dlopen. A widely adopted mechanism is to look for each module in
directories listed in an environment variable specific to your
application, allowing your users to inform the application of the
location of any modules they have written. If a suitable module is not
yet found, the application would then default to looking in a list of
standard locations – say, in a subdirectory of the user’s home
directory, and finally a subdirectory of the application installation
tree. For application ‘foo’, you might use
‘/usr/lib/foo/module.so’ – that is, ‘$(pkglibdir)/module.so’
if you are using Automake.
This algorithm can be further improved:
$ m4 --help Usage: m4 [OPTION]... [FILE]... ... Dynamic loading features: -M, --module-directory=DIRECTORY add DIRECTORY to the search path -m, --load-module=MODULE load dynamic MODULE from M4MODPATH ... Report bugs to <firstname.lastname@example.org>.
|[ < ]||[ > ]||[ << ]||[ Up ]||[ >> ]|
This document was generated by Ben Elliston on July 10, 2015 using texi2html 1.82.