On Wed, 2002-08-21 at 19:13, Henrique de Moraes Holschuh wrote: > 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. This is an another problem that would be easily and compatibly solved by my ELF extension (until the library gets properly fixed upstream). Anyway we really need to implant into the library developers' brains the concept that symbol names must be *globally* unique, not just unique to filename and that they either put the version number in the symbol (e.g. sasl1_explode vs. sasl2_explode) and use #define's to keep source compatibility or they use GNU/Solaris versioned symbols. We should also alert upstream of this kind of problems _before_ new versions get released and binary compatibility makes them untouchable.
Attachment:
signature.asc
Description: This is a digitally signed message part