* Torsten Landschoff (torsten@debian.org) wrote: > At first sight this looked (for me) like making sense and having no > negative implications. Of course reality was different - ldconfig had > problems setting the right symbolic links. setting the right symbolic links? It's not being used to set the symbolic links any different than it was before, it's just at the end we twiddle them a bit because having both libraries was a serious problem. > Today I found out the reason. It was not that it just removes symbolic > links it can't make sense of. Rather the problem is that the SONAME of > that library now does not match the name anymore. Well, no, but the linker can handle that. > libldap.so.2 used to have the SONAME libldap.so.2 as you would expect :) > Now the libldap.so.2 is a symlink to libldap_r.so.2 which has SONAME > libldap_r.so.2. > > I wonder which implications that could have when applications are > linking to libldap.so.2 (as the SONAME is no longer found). Nothing should care except for the runtime linker, which should handle the situation correctly. > Therefore I thought it might be a good idea to relink libldap_r.so.2 > using libtool and create libldap.so.2 with matching soname. Now I wonder > what will happen if some program decides he wants to link both > libldap.so.2 and libldap_r.so.2. All hell breaks loose, that's what caused the various RC bugs I closed with the message above. You end up randomly getting one set of symbols that expects to do threading and locking and another set that doesn't. > Suggestions how to fix that for real before getting sarge out of the > door with this risk that I don't feel I can estimate? Have you actually got a specific problem with the changes I did, or really, the results of them? There were a couple problems where people had old libldap2's hanging around (which is a rather serious mistake anyway...) but I havn't seen any other problems with that change yet... Thanks, Stephen
Attachment:
signature.asc
Description: Digital signature