mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-15 06:15:43 +00:00
5de84ec0c5
The LDAP tools code no longer has any knowledge of the NSS file names; the certpath2keypath() function has been deleted and we now simply use the certdbpath as keydbpath when it is provided (it makes no difference in the end). But note that because we need to maintain backwards compatibility, the libssldap code used by the ldapssl_.*_init() functions still knows the default name of the NSS module file (secmod.db), and the code also relies on the fact that the suffix for the key and cert files is ".db" and that the first letter in the main part of the name is either 'c' or 'k'. Also fixed a bug that caused the module file name specified on the LDAP tools command line (-m name) to be ignored. The ldapsearch and ldapcmp tools now exit with LDAP_NO_MEMORY if an LDIF fragment can't be constructed. Also fixed some issues reported by lint: Return values that were ignored. Make more functions and global variables static. Add /*ARGSUSED*/ and similar lint-friendly comments. |
||
---|---|---|
.. | ||
config | ||
ldap | ||
.cvsignore | ||
aclocal.m4 | ||
build.mk | ||
component_versions.mk | ||
configure | ||
configure.in | ||
gmakefile.win | ||
Makefile.in | ||
package.mk | ||
README.configure |
The autoconf files here are a minimal shim to allow the LDAP C SDK to build with autoconf. These are currently just a slightly modified version of the existing Makefile.client-based build system, merged with a copy of the NSPR autoconf stuff. As in the main browser tree, I've checked in the (generated) configure script so that autoconf isn't a prerequisite to build. My hope is that the owners of the C SDK will be interested in migrating to this build system, so that over time it can evolve into a true autoconf-style build system with all the goodies that go with that (ie configure-time feature tests for faster porting to new platforms, cross-compilation support, etc.). Comments to <news://news.mozilla.org/netscape.public.mozilla.directory>, please. Dan Mosedale <dmose@netscape.com>