I had recently been cross-building a proprietary application using a
version of headers and libraries dated from November and March.   One of
the libraries that this application uses is OpenSSL.  (libcrypto in
particular.)

When taking my application to a recent -current system, I find that it
won't run due to "Shared object "libcrypto.so.2" not found"

It appears that OpenSSL was recently (for some value of recently in the
last year) updated to version 3:


cabernet# ls -la /usr/lib/libcrypto*
lrwxrwxrwx  1 root  wheel  26 May  4  2006 /usr/lib/libcrypto.so ->
../../lib/libcrypto.so.3.1
lrwxrwxrwx  1 root  wheel  26 May  4  2006 /usr/lib/libcrypto.so.3 ->
../../lib/libcrypto.so.3.1
lrwxrwxrwx  1 root  wheel  26 May  4  2006 /usr/lib/libcrypto.so.3.1 ->
../../lib/libcrypto.so.3.1


I understand bumping minor numbers, but why was the major number
bumped?   Did the newer OpenSSL introduce API changes that are not
backwards compatible (for binary applications)?

I think changes like this should be avoided where ever possible, and
called out a bit more prominently when not possible, as this is the sort
of nightmare that makes ISV lives much harder.  (And one of the main
headaches in the Linux world, where it is almost impossible to release a
single binary that Just Works on Linux.)

For comparison look at Solaris, where a lot of effort is made not to
break binary applications that adhere to published interfaces (and even
some non-published interfaces) -- even to the point of a guarantee of
compatibility from Sun.

We (NetBSD) make all kinds of effort to make *binary* programs from
earlier versions work at the syscall kernel layer, but if we go around
breaking library interfaces will nilly then it is all for naught, from
what I can see.  Unless we're saying that dynamically linked programs
are 2nd class when it comes to compatibility.  (I think this would be a
poor choice, but if that is the position of TNF, then it needs to be a
bit more prominently mentioned.)

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191