Dr. Stephen Henson wrote:
On Wed, Jun 29, 2005, Dan Nuffer wrote:
Dr. Stephen Henson wrote:
This means that changing this in the short term is likely to cause
widespread
application breakage which wouldn't be too popular :-(
Speaking as an application developer, I would willingly go through a
one-time source code upgrade to achieve binary compatiblity. That is
more appealing to me than having to repeatedly deal with binary
compatiblity issues, because it's less work in the long run.
Also speaking as an application developer so would I. However there are a hell
of a lot of applications out there that depend on the existing APIs not
changing (too) much.
One possibility is to fork 0.9.x into maintenance mode for those apps.
I'm sure there's lots of reasons that would be painful, but I think
sometimes a library has to make this sort of transition in order to make
a break with old APIs.
Can you give details of some of the binary compatibility issues you've come
across?
I'm not sure whether this is the Linux distros' fault or not, but you
can't build a binary dynamically linked to libcrypto or libssl and have
it work on more than a handful of distros.
Older Redhats set the soname to libcrypto.[0-3]
Newer Redhats sets the soname to libcrypto.4
SUSE sets the soname to libcrypto.0.9.7
so if you build it on redhat you can't run it on SUSE and vice verse.
--
Dan Nuffer
Vintela, Inc. http://vintela.com/
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
