On Wed, 21 Aug 2002, Torsten Landschoff wrote: > Just explain why it is the right thing to do. And I would like to stay > binary compatible with RedHat etc. if at all possible.
Well, apps like to be able to use libsasl, and libldap. They also like to use libc. And libc uses nss, which often admins want to use with nss-ldap. So libc ends up dlopening nss-ldap, that links to libldap, and through it, to libsasl. Now, apps often want libsasl2. ldap uses libsasl1. nss segfaults. It is the same libdb2/libdb3 hell we had a while back. The proper fix is to have libsasl with versioned symbols, libldap with versioned symbols (so that we don't go all over the same problem when libldap gets updated -- right now the problem is sasl, not libldap). Every lib and app that links to sasl needs to be recompiled, btw. The idea of versioning libldap now is to reduce the amount of recompiling we would need when the next libldap comes. As for RH, we should get them to version their libs exactly as we would be doing as well. Same for the LSB requirements. Versioning symbols is backwards-compatible: stuff compiled against non-versioned libs will work with the versioned ones. However, stuff compiled against the versioned libs will want a lib with that exact versioning, and it will not accept the non-versioned libs AFAIK. The versioning should use the soname, so that we avoid symbol clashes with other versions of the same libs, AND with other libs as well. This is how glibc does it. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh
