Wouldn't the binary compatibility only work the other way? I.e. if you have an app written against 1.0.0 and then later drop in 1.0.1 binaries (since maybe some other app needs that), then that should work and your app should not break.
If you compile against 1.0.1 headers wouldn't the assumption be that you are now on the leading edge of the compatibility issue and are using a 1.0.1 binary? .................................... Erik Tkal Juniper OAC/UAC/Pulse Development -----Original Message----- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of sa...@zxid.org Sent: Wednesday, September 26, 2012 10:13 AM To: st...@openssl.org; r...@openssl.org Cc: openssl-users@openssl.org; sa...@zxid.org Subject: Re: libs version are 1.0.0 after compiling openssl 1.0.1c "Dr. Stephen Henson" <st...@openssl.org> said: > On Tue, Sep 25, 2012, Thakur, Praveen Kumar wrote: > > > I don't see any issue if .so files extension is 1.0.0. However, I wanted to > > confirm that is this a defect with 1.0.1 release? Or am I missing something. > > The 1.0.1 release should be binary compatible with 1.0.0, any > discrepancies should be fixed as they are bugs. For a brief > explanation of the versioning scheme see: When using software compiled against 1.0.1c headers with 1.0.0 libraries from debian, I get following core dump ssl_sess_cert_free, bad reference count (gdb) bt #0 0x0053e416 in ?? () #1 0x002e1c8f in raise () from /lib/i386-linux-gnu/libc.so.6 #2 0x002e52b5 in abort () from /lib/i386-linux-gnu/libc.so.6 #3 0x00624986 in ssl_sess_cert_free (sc=0x90c6510) at ssl_cert.c:275 #4 0x00626888 in SSL_SESSION_free (ss=0x90b44c8) at ssl_sess.c:280 #5 0x0061f58e in SSL_free (s=0x90a3d00) at ssl_lib.c:219 #6 0x0805018f in hi_close_final (hit=0xbfbd4e78, io=0x90a1458, lk=0x81361de "hi_read") at hiios.c:76 #7 0x0804fa2c in hi_close (hit=0xbfbd4e78, io=0x90a1458, lk=0x81361de "hi_read") at hiios.c:76 #8 0x08061e67 in hi_read (hit=0xbfbd4e78, io=0x90a1458) at hiread.c:47 #9 0x0805236c in hi_in_out (hit=0xbfbd4e78, io=0x90a1458) at hiios.c:76 #10 0x080540cd in hi_shuffle (hit=0xbfbd4e78, shf=0x90a0d28) at hiios.c:76 #11 0x0804e96b in main (argc=0, argv=0xbfbd4fc4, env=0xbfbd4fc8) at zxbusd.c:170 (gdb) The core dump does not happen if I statically link against 1.0.1c libraries. The usage is multithreaded server with ClientTLS connection. Nonblocking io with epoll loop and delayed accept. The bug reproduces about 25% of the time. It requires at least 3 threads and two TLS clients to reproduce. Cheers, --Sampo > http://www.openssl.org/support/faq.html#MISC8 > > Steve. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
