apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guenter Knauf <fua...@apache.org>
Subject Re: need a solution with APR DSO
Date Mon, 10 Aug 2009 15:29:10 GMT
Hi Bill,
William A. Rowe, Jr. schrieb:
> -1... yes it might be present, but it is a waste of process resource
> to have a fixed binding for the 90% of apr apps that don't make ldap
> queries.  The idea is to pull in only the bindings used and save
> a bunch of effort in the run time linker resolution table.  It gets
> worse and worse as apr offers more lib support.  And this is nothing
> more than what 'just in time' run time linking does, anyways, only
> we rolled our own.  Do we need 15 additional libraries loaded for
> 'hello world'?
> Aside from which, there are three clients that can reasonably be
> expected to be plugged in on win32; openldap, netscape or microsoft.
four: + Novell CLDAP - works great :)
> As this is further abstracted, it becomes easy to substitute to
> work around interop quirks with different servers (although never
> 'all at once', more of a 'pick one' solution).
> However Netware wants to handle it is fine, but we certainly don't
> want Windows to regress here.
sorry, but you completely missed the subject in first place here -
before we talk about what should be default or what not we need to agree
about a proper way how we handle to build one 'driver' as DSO and link
another 'driver' statically; once this is done everyone can simply
decide with a define change; currently this is impossible, and is like
we both said: only all or nothing.
So I'd suggest that we decouple the dynamic 'driver' builds from
APU_DSO_BUILD, and add separate defines for it, like:


View raw message