Paul Querna wrote: > William A. Rowe, Jr. wrote: >> Justin Erenkrantz wrote: >>> On Fri, Jan 2, 2009 at 3:57 PM, William A. Rowe, Jr. >>> <[email protected]> wrote: >>>> I don't know that we have any active interest in 2.0.0 at this moment, >>> Since I guess trunk is now 2.0.0, here's what I'd like to see: >>> >>> 1. fold in apr-util >> >> +1, with the dso approach, it is not so harmful for apps to link to it, >> and it solves the mutex initialization problems reported by Joe. If this >> means apr-util/trunk disappears, that's fine. > > Yeah, we need to sketch out how the DSO loading works API wise, and do > it in a generic way, such that most of the symbols exist in the main > library, but at runtime we can pull in a bunch of libraries. > > For example, apr_ldap_open or apr_dbm_open should exist, but we > shouldn't hard link to libldap or libdb46 instead perhaps have shim > shared DSOs that we load, libapr-ldap.so, which are linked to them. I > think an approach like this could work on most Linux/BSD/OSX type > places, but I'm sure it will have problems on some rarer unix OS.
We don't hard link to libdbXX anymore :) Catch up with us here LOL. The apr_ldap api should either be dumped or made a full abstraction, it's a crufty design. > But doing this is anotheer reason to do it in SCons, it would make all > the dynamic/static libs compiling much easier. Hmmm. I'm far from convinced, you'll have to demonstrate a flaw in the current schema to convince me :) >>> and apr-iconv into apr trunk. >> >> -1; we need a different solution. citrus, something based on the work of >> the perl community (automated), or even IBM's ICU. There isn't the long >> term interest in maintaining this. > > Do we even need it at all? Can't we just remove it and tell people to > use IBM's ICU? (or another library?) That's the point. Maybe multiple interfaces from apr_xlate into icu (I didn't see the mapping, but this is a version major bump so we might be able to identify a common api) or libiconv. Either way, this falls into the dso binding strategy as well.
