0.9.8o and 1.0.0a are not binary compatible.
And they're very old anyway :)
Closing ticket.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development
My apologies for my ignorance in misunderstanding where you were going on
1.0, compatibility-wise. It all seemed so close...
Indeed, the 1.0 EVP_MD_CTX size change already bit me, but only because I
had embedded the struct in one of my structs, bad coding anyway. If I let
the DLL allocate the
Hi guys:
I'm probably wrong here, but it looks like you've changed some function
prototypes, e.g., aes.h, in version 1.0.0a to size_t from unsigned long in
0.9.8o.
E.g.,
0.9.8o, AES.H:
void AES_ctr128_encrypt(const unsigned char *in, unsigned char *out,
size_t length, const AES_KEY *key,
Hi,
As far as I know, OpenSSL 1.0 is not meant to be binary compatible with
OpenSSL 0.9.8x, at least for low-level APIs like the AES one you are
referring to.
So, as you suggest it, an application should know if it is using a 0.9.8
libeay32 or an 1.0 one, and depending on that it will use
Hi,
As far as I know, OpenSSL 1.0 is not meant to be binary compatible with
OpenSSL 0.9.8x, at least for low-level APIs like the AES one you are
referring to.
So, as you suggest it, an application should know if it is using a 0.9.8
libeay32 or an 1.0 one, and depending on that it will use
Hi,
I mentioned only the low-level APIs because at the time of my writing I
remembered only these.
Actually, there are also breaking changes in high-level APIs between the
0.9.8 and the 1.0 series. For example, if you look at the EVP high-level
API, you'll notice that new fields have been
