Hi Joerg,<br><br><div class="gmail_quote">2012/7/23 Joerg Schilling <span dir="ltr"><<a href="mailto:Joerg.Schilling@fokus.fraunhofer.de" target="_blank">Joerg.Schilling@fokus.fraunhofer.de</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">> Here is the problem I want to solve:</div><div class="im">
> application APP1 is linked against libB.so.2 and libC.so.1<br>
> libC.so.1 is linked against libB.so.1<br>
> libB.so.1 and libB.so.2 have incompatible sonames.<br>
><br>
> At runtime, I want:<br>
> - APP1 libB symbols to be linked against libB.so.2,<br>
> - libC.so.1 libB symbols to be linked against libB.so.1.<br>
><br>
> Currently, what I have is:<br>
> - APP1 libB symbols linked against libB.so.2 (that's ok),<br>
> - libC.so.1 libB symbols linked against libB.so.2 (that's not good)<br>
<br>
</div>Why is this not good? Is libB.so.2 incompatible to libB.so.1?<br>
<div class="im"><br></div></blockquote><div><br></div><div>Yes they are incompatible. libB.so.2 has a different soname, it is not ABI compatible with libB.so.1</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<br>
> The reason I want this is that I would like to be able to gracefully handle<br>
> a library soname upgrade for libraries like openssl.<br>
> Currently as openssl is directly linked by a lot of libraries and binaries,<br>
> when you provide a new library (with incompatible soname), you have to<br>
> recompile and upload all the reverse-dependant packages at the same time to<br>
> be sure not to have a situation like described above.<br>
><br>
> This takes a lot of time and needs a lot of coordination.<br>
<br>
</div>A library upgrade works easy if the author of the library is careful, keeps<br>
the same soname and does not introduce incompatible changes but only compatible<br>
enhancements.<br></blockquote><div><br></div><div>Well, libraries authors change the soname from time to time when they don't want to maintain the ABI compatibility for some reason.</div><div>I do agree there should not be any problem if the soname is kept and if the ABI compatibility is maintained by the authors.</div>
<div>But the case here is a library upgrade with a soname/ABI modification.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> > Symbol versioning however allows to link against an older version of the<br>
> > library at runtime than the one that was used at compile time - given that<br>
> > the<br>
> > user does not need the new features of younger library versions.<br>
> ><br>
><br>
> Yes I do understand that. It allows a binary compiled against openssl 1.0.1<br>
> to work against openssl 1.0.0 if the binary only used functions compatibles<br>
> with openssl 1.0.0 (openssl 1.0.1 and openssl 1.0.0 provide the same soname<br>
> libssl1.0.0 but openssl 1.0.1 may have added new functions).<br>
> And if the binary used a openssl 1.0.1 specific function, the linker will<br>
> prevent you from running the binary on a computer with the openssl 1.0.0<br>
> library, even though the openssl 1.0.0 provides the same soname.<br>
><br>
> But I also expected the symbol versioning to work at the symbol level (and<br>
> not at the library level) so the linker will also use that information to<br>
> understand against which library each symbol must be linked, in case the<br>
> same symbol is provided by two libraries loaded at runtime.<br>
<br>
</div>Library versioning works at symbol level. Maybe your mapfile is not correct.<br>
Given the fact that the same mapfiles work on Solaris and Linux, I am not<br>
convinced that Linux is different.<br></blockquote><div><br></div><div>Yes, its works at the symbol level but:</div><div> - the linker doesn't seem to use that information when it links a given symbol, it only uses it to check wether or not it can load a library,</div>
<div> - it is not registered at the symbol level in the solaris elf file (that could perfectly work without it, but it seems that the version is stored for each symbol in Linux elf files).</div><div> </div><div>But I may have done something wrong, you could have a look at my previous email to see the tests I made (I showed the output of pvs to check if the symbol versioning information was there) and I just commited my modifications so you can have a look on svn:</div>
<div> - the mapfiles are here: <a href="http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.engines">http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.engines</a> , <a href="http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libssl">http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libssl</a> and <a href="http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libcrypto">http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/map.openssl.libcrypto</a></div>
<div><br></div><div> - the modification I've made are in this patch: <a href="http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/0007-enables-symbols-versioning.patch?revision=18832&view=markup">http://gar.svn.sourceforge.net/viewvc/gar/csw/mgar/pkg/openssl1/trunk/files/0007-enables-symbols-versioning.patch?revision=18832&view=markup</a></div>
<div> Basically I've just added the "-M" option.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
</div></div>SSLeay may have version tags for more than version but there cannot be<br>
different SSLeay implementations.<br></blockquote><div><br></div><div>Well it is the case here. </div><div> - libcrypto.so.0.9.8 provides the SSLeay symbol.</div><div> - libcrypto.so.1.0.0 also provides the SSLeay symbol.</div>
<div> - but these 2 libraries are not ABI compatibles so we're not supposed to link against libcrypto.so.1.0.0 a SSLeay symbol present in a binary that was compiled against libcrypto.so.0.9.8.</div><div><br></div><div>
Tell me if I understand something wrong here.</div><div><br></div><div>Thanks for your </div><div><br></div><div>Yann</div><div><br></div></div>