apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From david reid <da...@jetnet.co.uk>
Subject Re: dyanmic loading revisited
Date Wed, 14 Feb 2007 21:16:50 GMT
William A. Rowe, Jr. wrote:
> david reid wrote:
>> I've been contemplating some pieces of functionality for apr-util, but
>> run into the whole "it's a kitchen sink" thing again. We've discussed a
>> few times having apr-util modules dynamically loaded and I think it
>> might be time to look at making this a reality.
> +1 - some thoughts...
> I don't have an issue with statically linking the stubs for the
> libraries used to the
> applications which want to consume them, and moving everything into APR
> (dumping apr-util), provided there is no dynamic linkage from APR itself
> into
> the unnecessary libraries.  No libldap/liblber binding to those .so's
> for an app
> or lib that isn't trying to speak ldap, etc etc.
> As long as apr itself has few 'hard' dependencies (lib not found moving from
> box to box, entry point not found on a slightly older client lib), I
> don't see any
> further win to continue the split between apr and apr-util.
> If we want it truly dynamic that's possible too.  I'm thinking of
> something more
> sip-like, more like what you get in perl or python consuming external libs.
> (I'd list PHP except for how often folks just roll that whole campground
> into
> a single sleeping bag of one library including extensions.)
> Finally I don't want 'two options' - we don't want a redhat, for
> example, to ship
> apr with fixed support for the openldap/openssl/mysql they ship, and
> then to find
> that you can't use a postgres client without rebuilding the whole damned
> library.
> Let's make it flexible enough that packagers/distributors can't box
> their way into
> a corner?

I agree with most of the above. I'd say that to move this forward we
need to define where we want to end up and then start taking the steps
to get there. For me the list of "boxes to be ticked" would be

- generic module loading/tracking support within apr
- error handling to be made available (i.e. allow modules to define
error codes and error messages)
- figure out how we handle building using optional modules

When I talk about generic modules I'm not taling about simple dynamic
loading, but rather some "apr module" structures/definitions that allow
us to track things like versions and perhaps even dependencies. Such a
generic scheme would probably be of use to other apps as well (such as

For the build, I imagine something akin to apxs would be needed, which
would install both the module and the headers that it needed while
adjusting the build flags accordingly. Whether this is possible to do
cleanly on every platform I have no idea, though I suspect a few people
here will have more idea :-)



View raw message