such operation can be considered as breaking binary compatibility. However!
OPNESSL_ia32cap_P is accessed by application through pointer returned by
OPENSSL_ia32cap_loc() and such change of *internal* OPENSSL_ia32cap_P
declaration is possible specifically on little-endian platforms, such as
x86[_64] ones in question. In addition, if 32-bit application calls
OPENSSL_ia32cap_loc(), it clears upper half of capability vector maintaining
the illusion that it's still 32 bits wide.
compiled into *our* aplpications. That's because mingw is always
consistent with itself. Having library-side code linked into .dll
makes it possible to deploy the .dll with user-code compiled with
another compiler [which is pretty much the whole point behind Applink].
Changes marked "(CHATS)" were sponsored by the Defense Advanced
Research Projects Agency (DARPA) and Air Force Research Laboratory,
Air Force Materiel Command, USAF, under agreement number
F30602-01-2-0537.
and make all files the depend on it include it without prefixing it
with openssl/.
This means that all Makefiles will have $(TOP) as one of the include
directories.
"Jan Mikkelsen" <janm@transactionsite.com> correctly states that the
OpenSSL header files have #include's and extern "C"'s in an incorrect
order. Thusly fixed.
in cryptlib.h (which is often included as "../cryptlib.h"), then the
question remains relative to which directory this is to be interpreted.
gcc went one further directory up, as intended; but makedepend thinks
differently, and so probably do some C compilers. So the ../ must go away;
thus e_os.h goes back into include/openssl (but I now use
#include "openssl/e_os.h" instead of <openssl/e_os.h> to make the point) --
and we have another huge bunch of dependency changes. Argh.
