apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: need a solution with APR DSO
Date Mon, 10 Aug 2009 15:15:27 GMT
Mladen Turk wrote:
> On 09/08/09 03:56, Guenter Knauf wrote:
>> so this means for the NetWare build: either have set APU_DSO_BUILD=0 in
>> order to build LDAP static and then no DBD driver at all, or have set
>> APU_DSO_BUILD=1 and be forced to build LDAP as DSO.
>> If we have already an own define APU_DSO_LDAP_BUILD - why cant we just
>> move its setting into apu_config.h and each platform can set it as it
>> fits?
>> please comment!
> Same situation on Windows where there is always winldap present.
> See no reason why would this need to be compiled as DSO.
> IMHO every module should have an configure option to either
> build statically or as DSO, not as right now (all or none)

-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.
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.

View raw message