On Fri, Nov 23, 2007 at 10:55:14AM -0600, William Rowe wrote: > Joe Orton wrote: >>> If LDAP/expat/ssl can be similarly refactored, and only dynaload once the >>> specific apr object is initialized, >> Can you be more specific about what you are proposing here? Only >> "dynaload" what exactly? The actual LDAP/expat/ssl library? > > Linkages; > > yourapp > \-- apr-2.so.0 ( > \-- libc etc > on apr_ssl_init/open, loads... > > apr_ssl-2.so.0 > \-- libssl.so.0.9.7 > libcrypto.so.0.9.7 > > So until an app invokes apr_ssl_foo(), nothing's consuming memory.
This describes the way the DBD/DSO code works now. This type of arrangement is perfect for code which has vtable-like abstractions on top of the third-party library, as DBD does, but doesn't really work for anything else. For e.g. the LDAP code this is simply not realistic at all without completely rewriting the code to provide a real abstraction; currently the LDAP code *requires* a dependency between application and the ABI of the underlying LDAP toolkit - i.e. direct library linkage. joe
