Linux Plugins
(Created page with '<!-- Page info --> {{Title|Linux Plugins}} {{Category|Manual}} <!-- Page info end --> == Building plugins == The shared objects technology is used, among other things, to provi…') |
(→Building plugins: adding link to libltdl at gnu.org) |
||
| Line 7: | Line 7: | ||
The shared objects technology is used, among other things, to provide the so-called “plug-in system”, that allows us to link in compiled code at runtime providing (eventually optional) features [http://www.flameeyes.eu/autotools-mythbuster/libtool/plugins.html]. | The shared objects technology is used, among other things, to provide the so-called “plug-in system”, that allows us to link in compiled code at runtime providing (eventually optional) features [http://www.flameeyes.eu/autotools-mythbuster/libtool/plugins.html]. | ||
| − | Software that is interested in wider portability among different operating systems will be interested instead in using the wrapper library and interface called libltdl. | + | Software that is interested in wider portability among different operating systems will be interested instead in using the wrapper library and interface called libltdl [http://www.gnu.org/software/libtool/manual/html_node/Using-libltdl.html]. |
| + | |||
= Using libltdl for plug-ins = | = Using libltdl for plug-ins = | ||
Because of the wide adoption of libltdl in many types of applications, it's support in autotools is available with huge flexibility. This is because it's wrapping abilities can easily be used on systems where libtool proper is not usually installed, and thus it's often convenient to have a local copy of it. | Because of the wide adoption of libltdl in many types of applications, it's support in autotools is available with huge flexibility. This is because it's wrapping abilities can easily be used on systems where libtool proper is not usually installed, and thus it's often convenient to have a local copy of it. | ||
Revision as of 15:09, 26 November 2010
Building plugins
The shared objects technology is used, among other things, to provide the so-called “plug-in system”, that allows us to link in compiled code at runtime providing (eventually optional) features [1]. Software that is interested in wider portability among different operating systems will be interested instead in using the wrapper library and interface called libltdl [2].
Using libltdl for plug-ins
Because of the wide adoption of libltdl in many types of applications, it's support in autotools is available with huge flexibility. This is because it's wrapping abilities can easily be used on systems where libtool proper is not usually installed, and thus it's often convenient to have a local copy of it. This is wrong, on linux system the used of the system library libltdl should be require, like any other required libraries.
There is no provided macro to check for the library in the system to simply rely on that; since it also does not provide a pkg-config datafile, the best practices choice is simply to discover the library through AC_CHECK_LIB.
To do that you can use the following snippet of code, for instance:
Example 3.4. Checking for libltdl
AC_CHECK_HEADER([ltdl.h],
[AC_CHECK_LIB([ltdl], [lt_dladvise_init],
[LIBLTDL=-lltdl], [LIBLTDL=])],
[LIBLTDL=])
It's important to check for a function that is present in the currently-supported version of libltdl. This snippet checks for the lt_dladvise_init function that is a new interface present in libtool 2.2 and later.
