On Feb 24, 2009, at 1:01 PM, richm(a)stanfordalumni.org wrote:
> Perhaps a better question is - how would you like it to work?
I prefer that we leave the builder with as freedom as possible.
Right, that makes the most sense.
> I'm assuming there must be some way specify which crypto you
> openldap with - is that a configure option?
Presently there is:
I assume we'd just add an 'nss' option to the above. However, Howard
might have other things in mind.
Yes (but the option will be "moznss").
>>> that both NSPR and NSS support pkg-config
>> Here would be to ensure that the proper pkg-config is in the PATH.
>> Of course, pkg-config stuff gets stuff into the environment in some
>> fixed order, which does take away some freedom from the builder. I
>> guess the builder can always manually adjust the order (by providing
>> CPPFLAGS, etc., directly) and then provide a pkg_config which does
>> little. So the freedom is there, just harder to take advantage of.
> The original patch -
> assumes the use of pkg-config - I suppose that is not sufficient.
My only concern would be whether or not pkg-config use here is
specific to a particular 3rd party packaging of NSS versus something
available with all installs of NSS.
I currently build against a copy of NSS in my Mozilla build tree. There's
nothing installed with pkg-config. I would like to avoid a dependency on
Also, the patch uses the OpenSSL-compatibility stuff in NSS. The current code
in HEAD uses NSS natively, and I'd prefer not to have the -compat dependency
as well. That's a key requirement to me personally, because otherwise it will
not interoperate with Mozilla/Seamonkey, and right now that's my primary goal
for this work.
It's been a few months since I last looked at this and it took me a while to
remember all the issues surrounding it...
There are two major problems with the current MozNSS support in HEAD:
1) It does no initialization of its own. This works with Seamonkey/Thunderbird
because the main app has already initialized the NSS library; libldap just
uses the state that's already there. Code to initialize properly when NSS
hasn't already been initialized still needs to be written.
2) It cannot shutdown safely. This is a weakness in the NSS API that was
discussed at length in the Mozilla newsgroups. Unfortunately that discussion
went nowhere. (The NSS_Shutdown() function tears down the library
unconditionally; if there were multiple callers of the library and one of them
shuts down because it's going away, all of the other callers lose the library
Another problem I've had in integrating is that the documentation is out of
date with the code - the docs recommend certain APIs and practices that are
actually deprecated in the actual code. This has led down a lot of blind
alleys/dead ends that could otherwise have been avoided...
I'll be leaving the actual technical review of your patch to
other active committers.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/