So I did the tests and ... it doesn't work.<div><br></div><div>I recompiled libssl0.9.8 with symbol versioning enabled.</div><div>I recompiled libneon against this libssl0.9.8 library.</div><div>I recompiled cadaver against libssl1.0.0 with symbol versioning enabled.</div>

<div><br></div><div>The result is:</div><div><br></div><div>- libssl0.9.8 compiled fine with symbol versioning enabled:</div><div><br></div><div><div># pvs /opt/csw/lib/libssl.so.0.9.8 </div><div>        libcrypto.so.0.9.8 (OPENSSL_0.9.8);</div>

<div>        libc.so.1 (SUNW_0.7, SUNWprivate_1.1);</div><div>        libssl.so.0.9.8;</div><div>        OPENSSL_0.9.8;</div></div><div><br></div><div>- the libneon27 effectively registered the dependancy on the OPENSSL_0.9.8 symbols:</div>

<div><br></div><div><div># pvs -r /opt/csw/lib/libneon.so.27.2.6 </div><div>        libssl.so.0.9.8 (OPENSSL_0.9.8);</div><div>        libcrypto.so.0.9.8 (OPENSSL_0.9.8);</div></div><div>[...]</div><div><br></div><div>- but the linker still links the libneon ssl symbols with openssl 1.0.0 when I launch cadaver:</div>
<div><span style="background-color:rgb(255,255,255)"># </span><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px">LD_DEBUG=all</span><span style="background-color:rgb(255,255,255);color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"> /opt/csw/bin/cadaver</span></div>

<div><br></div><div>[...]</div><div><div>18581: version needed processing: file=/opt/csw/lib/i386/libneon.so.27</div><div>18581:             file                        version</div><div>18581:             libssl.so.0.9.8             OPENSSL_0.9.8</div>

<div>18581: </div></div><div>[...]</div><div><div>18581: 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><div>[...]</div><div><br></div><div>

<br></div><div>So I am really surprised but the conclusion is that solaris symbol versoning doesn't help in this case.</div><div>It seems the version check is only done to see if the whole library can be loaded (and only if the application/library and the library both use versioning), but it is not used after to link the symbols.</div>

<div><br></div><div>From what I understood, symbol versioning in Linux works at the symbol level and would effectively help to prevent the kind of problem we have here.</div><div><br></div><div>But for now I don't see a way to avoid the same painful transition in the future. I still welcome any light on symbol versioning because I may have missed something.</div>

<div><br></div><div>Yann</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br><br><div class="gmail_quote">2012/7/22 Peter FELECAN <span dir="ltr"><<a href="mailto:pfelecan@opencsw.org" target="_blank">pfelecan@opencsw.org</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Yann Rouillard <<a href="mailto:yann@pleiades.fr.eu.org" target="_blank">yann@pleiades.fr.eu.org</a>> writes:<br>


<br>
> I will try to compile a libssl0.9.8 with symbol versioning to really test<br>
> if this would help during a library migration.<br>
<br>
</div>This is the most probable solution, i.e., to have only versioned<br>
libraries installed; it will let binaries compiled with non versioned<br>
libraries to execute, which is what we wish, isn't it? However, which<br>
library is used is pending a test; I bet 2 drachmas that the highest<br>
version is used...<br>
<span><font color="#888888"><br>
--<br>
Peter<br>
_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@lists.opencsw.org" target="_blank">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. ::.<br>
</font></span></blockquote></div><br></div>