libtool
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]