[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Linking automatically with dlopen
From: |
Reuben Thomas |
Subject: |
Re: Linking automatically with dlopen |
Date: |
Thu, 19 Apr 2007 14:57:05 +0100 (BST) |
On Wed, 18 Apr 2007, Bob Friesenhahn wrote:
Years ago, I converted ImageMagick to use loadable modules in order to
decouple from optional libraries. This did require a clean "codec" interface
but it turned out fine. There are 95 modules, and libldtl is only used if
the package is built to use loadable modules. A module loader was developed
to keep track of loadable modules. Each module has load/unload routines and
registers itself with the library by invoking a module adding function in the
main library.
Thanks for the tips. I've had a look at the ImageMagick sources, which
presumably (and seemingly) still use your scheme, and the good news (for me)
is that it looks like I can do what I want without changing my existing
modules (which already have a clean interface). Still, it would be nice if
it could be done fully automatically, something like:
libtool --mode=link --dlopenlink=foo,bar,baz ...
If -lfoo, -lbar or -lbaz appears in the command line, the relevant library
is not linked against. Instead, a dummy module will be compiled that
contains two functions: one that that attempts to open the library and
resolves the relevant symbols, which is called on program startup, and
another which returns a value saying whether the given library was
successfully opened.
[Inessential features: it would be nice if the initialisation functions
could be called automatically; if not, they could be called by a libtool
initialisation function, which means that the total code impact would be
just a few lines:
#include <ltdl.h>
...
lt_dlinit();
lt_dlautoopen();
...
which has the advantage that the programmer can choose when to take the (in
general potentially large) hit of doing the dlopening. It would also be nice
if the program could easily test whether an individual symbol had been
resolved by testing whether or not it was NULL.]
It seems to me that this could be implemented relatively easily: first, call
the linker normally, then find out which libraries (if any) in the
dlopenlink link have been pulled in, then scan the object to discover which
symbols from each library have been imported; generate and compile the
appropriate stub, and then perform the link again, without the relevant
libraries, but with the stub.
I admit that this buys me very little in my particular case: it seems that I
can indeed get away with a little build system hackery and merely change the
module that knows about all the CODEC and effect modules in SoX. That's nice
to learn, and it's probably what I'll do. I'm interested, though, to know
whether the general case is worth solving. Perhaps it's not: maybe if your
program is dependent on a particular library in lots of places, then you
simply have to link against it. I suspect, however, that the same
considerations employed to justify aspect-oriented programming could be used
to justify the idea that a library could be used in many places in a program
(i.e. hard to isolate in the way that ImageMagick or SoX can isolate
transforming functions) and yet happily be present or not without making the
program break down. It would have to involve a large number of API calls (or
you can just proxy them) as well as a large number of modules from which
they are called.
--
http://rrt.sc3d.org/ | Psalms 19:12 <-- tagline for the guilty