<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 22/04/2015 21:49, Viktor Dukhovni
wrote:<br>
</div>
<blockquote cite="mid:20150422194911.GP25758@mournblade.imrryr.org"
type="cite">
<pre wrap="">On Wed, Apr 22, 2015 at 09:04:04PM +0200, Jakob Bohm wrote:
</pre>
<blockquote type="cite">
<pre wrap="">For parallel installation of OpenSSL 1.0.2a and the OS
supplied OpenSSL 1.0.1 (with patches equivalent to the
latest release), modify SHLIB_VERSION_NUMBER from 1.0.0
to 1.0.2 in the folliwing files from the tarball:
</pre>
</blockquote>
<pre wrap="">
The ABI version really is 1.0.0. Symbol versioning is the right
way to distinguish between 1.0.[012]. The Debian OpenSSL build
does symbol versioning to avoid conflicts between multiple libraries
that support the 1.0.0 ABI.
Yes, the ABI compatibility is only backwards compatibility, so
applications that link to a newer version of the library at compile
time, need to use the same or newer library at run-time.
Applications using a non-system library need to record a suitable
RPATH (often using "$ORIGIN" is a good bet if the application ships
a copy of the library). Ideally applications would use the system
supplied library, otherwise patching becomes rather difficult...
</pre>
</blockquote>
<tt>My observations were actually made on Debian. And I seem to
recall<br>
it</tt><tt> </tt><tt>was the system daemons that failed, not my
newly recompiled<br>
daemons,</tt><tt> </tt><tt>though I may of cause be mistaken.</tt><tt><br>
</tt><tt><br>
</tt><tt>As for symbol versioning, if that is not in the upstream
tarball,<br>
any such</tt><tt> </tt><tt>things added by vendor compiles is
just going to break<br>
the ABI, in fact</tt><tt> </tt><tt>the absence of symbol
versioning in my vanilla<br>
compile may be what</tt><tt> </tt><tt>caused the problems for all
the installed<br>
packages.<br>
</tt>
<pre class="moz-signature" cols="72">Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. <a class="moz-txt-link-freetext" href="http://www.wisemo.com">http://www.wisemo.com</a>
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded </pre>
</body>
</html>