Re: defines for each sasl mech?

[Julio Sánchez Fernández <j_sanchez@stl.es>]

"Kurt D. Zeilenga" wrote:
> Initially, it should be a configure option (which implied a set
> of macros that can be used to include the support).  Eventually,
> we'd like to support dynamically loadable SASL mechanisms and
> configuration control for which mechanisms to support.   That is,
> the code may be compiled with DIGEST-MD5, but the user may want
> to disallow it's use.  This will all get sorted out over time.

Let me add a reason for desiring dynamic loading of extensions,
especially when these extensions make use of additional shared
libraries.  I have recently suffered the following scenario.

I use both pam_ldap and nss_ldap and I linked them with the dynamic
libldap and liblber libraries.  And the latter make in turn use
of libssl and libcrypto, since I am using TLS.  Well, let's suppose
I try anything like ls -l.

The nss system looks at /etc/nsswitch.conf and finds out that I
resolve passwd with 'files' and 'ldap'.  It finds a user not in
'files', so it tries 'ldap'.  At that precise moment, nss_ldap is
loaded, but fails because it cannot resolve the references to the
SSL library.

That is, one had a perfectly functional nss_ldap (same goes for
pam_ldap) setup and replacing the shared LDAP libraries by new ones
having additional dependencies breaks it.

My workaround was to rebuild in a rush nss_ldap and pam_ldap to include
these new dependencies, but new libraries will only exacerbate the
problem.

Of course, statically linking would solve the problem, but would be
undesirable for other reasons.  This was on a Linux RedHat 6.0 with
glibc 2.1.

Julio