Hi Joerg,<br><br><div class="gmail_quote">2012/7/22 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">Yann Rouillard <<a href="mailto:yann@pleiades.fr.eu.org">yann@pleiades.fr.eu.org</a>> wrote:<br>
<br>
> It seems the version check is only done to see if the whole library can be<br>
> loaded (and only if the application/library and the library both use<br>
> versioning), but it is not used after to link the symbols.<br>
><br>
> From what I understood, symbol versioning in Linux works at the symbol<br>
> level and would effectively help to prevent the kind of problem we have<br>
> here.<br>
<br>
</div>I am not sure whether you have different expectations than what symbol<br>
versioning is.<br></blockquote><div><br></div><div>Well I expected it to work more like it does on Linux (more details below).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
What problem do you have and how do you like to solve it?<br></blockquote><div><br></div><div>Here is the problem I want to solve:</div><div> application APP1 is linked against libB.so.2 and libC.so.1</div><div> libC.so.1 is linked against libB.so.1</div>
<div> libB.so.1 and libB.so.2 have incompatible sonames.</div><div><br></div><div> At runtime, I want:</div><div> - APP1 libB symbols to be linked against libB.so.2,</div><div> - libC.so.1 libB symbols to be linked against libB.so.1.</div>
<div> </div><div> Currently, what I have is:</div><div> - APP1 libB symbols linked against libB.so.2 (that's ok),</div><div> - libC.so.1 libB symbols linked against libB.so.2 (that's not good)</div>
<div> </div><div> </div><div>The reason I want this is that I would like to be able to gracefully handle a library soname upgrade for libraries like openssl.</div><div>Currently as openssl is directly linked by a lot of libraries and binaries, when you provide a new library (with incompatible soname), you have to recompile and upload all the reverse-dependant packages at the same time to be sure not to have a situation like described above.</div>
<div><br></div><div>This takes a lot of time and needs a lot of coordination.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Symbol versioning cannot heal incompatible changes. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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 the<br>
user does not need the new features of younger library versions.<br></blockquote><div><br></div><div>Yes I do understand that. It allows a binary compiled against openssl 1.0.1 to work against openssl 1.0.0 if the binary only used functions compatibles with openssl 1.0.0 (openssl 1.0.1 and openssl 1.0.0 provide the same soname libssl1.0.0 but openssl 1.0.1 may have added new functions). </div>
<div>And if the binary used a openssl 1.0.1 specific function, the linker will prevent you from running the binary on a computer with the openssl 1.0.0 library, even though the openssl 1.0.0 provides the same soname.</div>
<div><br></div><div>But I also expected the symbol versioning to work at the symbol level (and not at the library level) so the linker will also use that information to understand against which library each symbol must be linked, in case the same symbol is provided by two libraries loaded at runtime.</div>
<div><br></div><div>This is how it works under Linux.</div><div><br></div><div>Do you know how to achieve this under Solaris, or how to solve the general library upgrade problem in a general manner ?</div><div><br></div><div>
Thanks in advance for your answer.</div><div><br></div><div><br></div><div>To explain how it works under Linux, here is a real exemple:</div><div><br></div><div> - I have a neon library directly linked against libcrypto and libssl 0.9.8</div>
<div><br></div><div># objdump -xT /usr/lib/libneon.so.27.2.6</div><div>[...]</div><div> NEEDED libcrypto.so.0.9.8</div><div><div> NEEDED libssl.so.0.9.8</div></div><div>[...]</div><div><div>0000000000000000 DF *UND*<span class="Apple-tab-span" style="white-space:pre"> </span>0000000000000000 OPENSSL_0.9.8 SSLeay</div>
</div><div>[...]</div><div><br></div><div> - I have a cadaver binary directly linked against libneon and libcrypto 1.0.0</div><div># objdump -xT /usr/bin/cadaver </div><div>[...]</div><div><div> NEEDED libcrypto.so.1.0.0</div>
</div><div><div> NEEDED libneon.so.27</div></div><div>[...]</div><div><div>0000000000000000 DF *UND*<span class="Apple-tab-span" style="white-space:pre"> </span>0000000000000000 OPENSSL_1.0.0 SSLeay</div>
</div><div>[...]</div><div><br></div><div> - at runtime, both libcrypto libraries are loaded and the linker correctly link cadaver and libneon with the good version of the library:</div><div># LD_DEBUG=all LD_BIND_NOW=1 cadaver</div>
<div>[...]</div><div><div> 21796: file=libcrypto.so.1.0.0 [0]; needed by cadaver [0]</div><div> 21796: find library=libcrypto.so.1.0.0 [0]; searching</div><div> 21796: search cache=/etc/ld.so.cache</div>
<div> 21796: trying file=/lib/x86_64-linux-gnu/libcrypto.so.1.0.0</div></div><div>[...]</div><div><div> 21796: file=libcrypto.so.0.9.8 [0]; needed by /usr/lib/libneon.so.27 [0]</div><div> 21796: find library=libcrypto.so.0.9.8 [0]; searching</div>
<div> 21796: search cache=/etc/ld.so.cache</div><div> 21796: trying file=/lib/x86_64-linux-gnu/libcrypto.so.0.9.8</div></div><div>[...]</div><div><div> 21796: binding file /usr/lib/libneon.so.27 [0] to /lib/x86_64-linux-gnu/libcrypto.so.0.9.8 [0]: normal symbol `SSLeay' [OPENSSL_0.9.8]</div>
</div><div>[...]</div><div><div> 21796: binding file cadaver [0] to /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 [0]: normal symbol `SSLeay' [OPENSSL_1.0.0]</div></div><div>[...]</div><div><br></div><div><br></div>
<div><br></div><div>Yann</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Jörg<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
<a href="mailto:EMail%3Ajoerg@schily.net">EMail:joerg@schily.net</a> (home) Jörg Schilling D-13353 Berlin<br>
<a href="mailto:js@cs.tu-berlin.de">js@cs.tu-berlin.de</a> (uni)<br>
<a href="mailto:joerg.schilling@fokus.fraunhofer.de">joerg.schilling@fokus.fraunhofer.de</a> (work) Blog: <a href="http://schily.blogspot.com/" target="_blank">http://schily.blogspot.com/</a><br>
URL: <a href="http://cdrecord.berlios.de/private/" target="_blank">http://cdrecord.berlios.de/private/</a> <a href="ftp://ftp.berlios.de/pub/schily" target="_blank">ftp://ftp.berlios.de/pub/schily</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@lists.opencsw.org">maintainers@lists.opencsw.org</a><br>
<a href="https://lists.opencsw.org/mailman/listinfo/maintainers" target="_blank">https://lists.opencsw.org/mailman/listinfo/maintainers</a><br>
.:: This mailing list's archive is public. ::.</div></div></blockquote></div><br>