Danek Duvall wrote: > Would the binding problems go away if you linked against openldap with > direct binding? I expect that direct binding can be used to ensure that two objects in the same process can use different LDAP libraries.
Here's an example I tried: Build APR-Util with OpenLDAP. Sample app uses APR-Util LDAP APIs; works fine. The app starts calling a shared library which uses native Solaris LDAP, but that shared library unexpectedly uses OpenLDAP when loaded into the APR-Util application. Relink the shared library with "-B direct". Now both pieces use the expected LDAP library. I don't think this is a magic solution for the web stack delivery though. The problem is going to occur when a user creates or otherwise adds some glue that loads something into Apache/PHP/etc. that uses native Solaris LDAP; that glue must bind directly to libldap.so regardless of how the web stack links to OpenLDAP, as I understand it. The user will see a problem and hopefully learn the solution and modify the build of the piece they added. > I also see that the library is linked against libsendfile > and libuuid, which are also unused -- perhaps -z ignore on the link would > help? > I'll experiment with that separately. (The libsendfile issue at least has a more appropriate solution.)
