Paul Risenhoover wrote:
I guess the question is, "How badly does it misbehave?" Is it
completely unusable or are their distinct modules (which I could
possibly disable) that are bad.
I *really* need Large File Support -- on Windows.
You may need to disable sendfile/mmap on Win32, but you should already
have it.
It's borked on most (all?) pre-2003 Server platforms; from my commit
for apr-util 1.2.2 (which isn't part of the 2.1.8-beta, but should be
in the 2.1.9-beta);
Correct the use-case checking to determine our ldap[ssl]_[ssl]init()
choice. This isn't platform specific, it must be based on our
apu_ldap.h configuration choices, APR_HAS_LDAP_SSLINIT and
APR_HAS_LDAPSSL_INIT are already flagged correctly on Netware, Win32.
And follow the APR_HAS_LDAP_START_TLS_S election on Win32, because
the platform SDK exports a binding to ordinals 330/331 for start/stop
TLS, but these entry points are missing on Windows 2000 Pro SP4, and
likely many other flavors of WLDAP32.DLL.
Note that the WLDAP32.DLL is bound by ordinals, not by fn names, so
VC98 for example provides an invalid wldap32.lib with the wrong
ordinal numbers. Only use the platform SDK, and use depends.exe to
ensure that the elected functions are correct. One good thing; the
VC98 flavor is an LDAPv2 toolkit, while the PSDK is an LDAPv3 which
passes the #ifndef/#error backstop. So it's unlikely a user will
bind to the wrong wldap32.lib if the LIB and INCLUDES paths on their
configuration keeps the VC and PSDK paths in the same order relative
to the other envvar.
In short... if ldap_start_tls_s isn't exported by your machine's
WSOCK32.DLL - httpd.exe will simply fail to start.
Bill
