Mladen, perhaps I failed to make my point below. *Today* you can build your very own apr for your app with whatever features enabled/crippled that you like.
The point I was illustrating below was a (future) way to build apr component by component, such that, for example, the apr_ldap lib and dependent libldap, liblber, libssl and libcrypto would only be loaded in process if your app actually chooses to link to libaprutil-2-ldap.so. But you can build your apr today without iconv if that's what you are trying to accomplish. William A. Rowe, Jr. wrote:
At the moment it hauls in a number of libraries, which makes moving binaries around a rather worthless exercise in futility. The right answer is to break apart apr-util into seperately loadable libraries in APR-util v2.0 - so that all those dependencies are split, and it begins to look alot more like the way that python, perl, and jar support of these various features break apart all the subdependencies. apr_xml becomes one lib, apr_xlate becomes another, apr_ldap becomes a third, etc.
