Hi Dago,<br><br><div class="gmail_quote">2012/6/20 Dagobert Michelsen <span dir="ltr"><<a href="mailto:dam@opencsw.org" target="_blank">dam@opencsw.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Hi Yann,<br>
<br><div>[...]</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>><br>
> As said before, it would be helpful to know when the dual runtime linking is really a problem, this would maybe help to significantly simplify the coordination work.<br>
><br>
> Does someone know what happens exactly when a program is linked with two different libraries at runtime by the way of one of its dependancy ?<br>
<br>
</div>The worst thing would be having two sets of global variables saving state for the different<br>
versions.<br>
<div><br></div></blockquote><div><br></div><div>I made some checks and it seems it is worse than that. When both openssl 0.9.8 and openssl 1.0.0 are linked at runtime, only one of the two libraries will be really used (if exported symbols are the same in both versions).</div>

<div><br></div><div>I did: LD_DEBUG=all  LD_BIND_NOW=1 /opt/csw/bin/cadaver</div><div>after having reinstalled the libneon27 linked with openssl 0.9.8.</div><div><br></div><div>The result is that every symbol is linked with openssl 1.0.0 even for neon that was linked against openssl 0.9.8 at compile time:</div>
<div><div>01278: binding file=/opt/csw/lib/i386/libneon.so.27 to file=/opt/csw/lib/i386/libssl.so.1.0.0: symbol 'SSL_pending'</div><div>01278: binding file=/opt/csw/lib/i386/libneon.so.27 to file=/opt/csw/lib/i386/libssl.so.1.0.0: symbol 'SSL_get_error'</div>
<div>01278: binding file=/opt/csw/lib/i386/libneon.so.27 to file=/opt/csw/lib/i386/libssl.so.1.0.0: symbol 'SSL_read'</div></div><div>[...]</div><div><br></div><div>even libssl0.9.8 is linked against libcrypto.so.1.0.0:</div>
<div>binding file=/opt/csw/lib/pentium_pro/libssl.so.0.9.8 to file=/opt/csw/lib/i386/libcrypto.so.1.0.0: symbol 'EVP_sha224'</div><div>[...]</div><div><br></div><div>It means that we are lucky that every packages dual linked with ssl0.9.8 and ssl1.0.0 already uploaded to unstable works. I suppose it just works because openssl 1.0.0 and 0.9.8 are ABI compatibles enough so that it works in most cases.</div>
<div><br></div><div><br></div><div>I suppose one possible solution to this problem would be to use versioned symbols. This was already mentioned in a previous thread I think. Does someone have some insights about the pros and cons of versioned symbols ?</div>
<div>Of course this would imply a new painful transition for openssl...</div><div><br></div><div><br></div><div>BTW, I also noticed that cadaver was directly linked with openssl 1.0.0 although it doesn't use any symbols from the ssl library. I will check exactly why but I suppose if would be an interesting additional check for checkpkg. Has anyone already looked in that problem ?</div>
<div><br></div><div><br></div><div>Yann</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>
 </div></div>