Hi everybody,<div><br></div><div>As you may have noticed, updating libssl from 0.9.8 to 1.0.0 is proving to be quite a pain.</div><div>As the linker tries by default to link a symbol against the first library loaded that provides the symbol, in our case that could easily lead to situation where a binary or a library is linked against the wrong library, leading to subtle bugs or crashes.</div>
<div><br></div><div>Linux uses symbol versioning to solve this problem but in the Solaris world, even if symbol versioning does exist, that is not the solution to this problem and it turns that a solaris linker feature called direct binding is a right approach (see the thread <a href="http://lists.opencsw.org/pipermail/maintainers/2012-July/017064.html">http://lists.opencsw.org/pipermail/maintainers/2012-July/017064.html</a> and the explanation in oracle manual: <a href="http://docs.oracle.com/cd/E19963-01/html/819-0690/aehzq.html">http://docs.oracle.com/cd/E19963-01/html/819-0690/aehzq.html</a> ).</div>
<div><br></div><div>Direct Binding changes the behaviour of the linker at runtime, when a program or a library has a direct binding against a library, the linker will now link a symbol against the exact library that provided the symbol at compile time. That exactly solves the problem we have here because openssl 0.9.8 symbols will be linked against libssl0.9.8 and not libssl1.0.0 (and vice versaà.</div>
<div><br></div><div><br></div><div>So to avoid futures difficulties of the same kind, I am proposing to enable direct binding by default for all opencsw software !)</div><div><br></div><div>One day or the other we will to handle an new ABI incompatible library which still provides the same functions (but maybe with subtle difference as ABI is not compatible). Openssl is the first big one but we will have others problem like this (libpng or libjpeg ?).</div>
<div>Currently, we have to pretty much upload together all the packages linked against the library, which turns out to be difficult to do as it requires a lot of coordination and blocks the upload of new packages in unstable. </div>
<div><br></div><div>Enable direct binding will definitely solve this problem and is also supposed to be more efficient, as it doesn't have to search for a symbol in all libraries.</div><div><br></div><div>I don't see a lot of cons, maybe these ones:</div>
<div>  - sometimes, it seems some programs do need the original linker behaviour but that could be fixed by some other ld options,</div><div>  - we never enabled it so maybe we will uncover some problems,</div><div>  - it works only with Sun ld (we don't use GNU ld somewhere do we ?)</div>
<div><br></div><div>To be it seems to have been enabled for opensolaris in the past:</div><div><a href="https://blogs.oracle.com/rie/entry/direct_binding_now_the_default">https://blogs.oracle.com/rie/entry/direct_binding_now_the_default</a></div>
<div><br></div><div>I am no expert in linking so I welcome any comment on that proposal.</div><div><br></div><div><br></div><div>But if everybody is ok with it, here is how we could try to enable it to gradually:</div><div>
<br></div><div> 1. write a checkpkg test to test if direct binding if properly enabled in a package,</div><div> 2. enable Direct Binding manually for a reduced set of packages (at least my packages :) ) </div><div>     (we just have to pass "-Bdirect" to SUN ld)</div>
<div> 3. wait a bit to see if something unexpected happens :)</div><div> 3. if it works, enable it by globally adding the option to LINKER_FLAGS</div><div> 4. enable the checkpkg direct binding test by default so we can catch even packages that don't use LDFLAGS</div>
<div><br></div><div><br></div><div>Thanks in advance for your comments,</div><div><br></div><div>Yann</div>