Riccardo,
it is nice to see how my messages are totally ignored...
As nice as to see how instructions in ./README are totally ignored:
" SUPPORT -------
If you have any problems with OpenSSL then please take the following steps first:
- Download the current snapshot from ftp://ftp.openssl.org/snapshot/ to see if the problem has already been addressed - Remove ASM versions of libraries - Remove compiler optimisation flags
"
I hope this doesn't mean that everybody is clueless.
Clues? Google for 3c48692aceb44f85cf99c985154c15b79e6baef0, which is your own hash value... gcc-bugs report from 2000 maintains that gcc 2.96 fails in exactly same way on PowerPC, but not 2.95.3... Does it sound like problem with test program? No, it sound like compiler bug...
Paul,
With the wide variety of platforms, it is not unusual for problems to show up on only one platform.
Yes, but when it does, it's more and more likely to mean that it's something wrong with end-developer environment, e.g. a compiler bug... Naturally provided that platform is correctly recognized by ./config...
I had a similar problem with MD4, MD5, RIPEMD and SHA on my system because some of the OpenSSL source code assumes that certain platforms have certain endian characteristics. In my case, the code tested the _i386 macro and decided the platform must be little endian.
This is wastly misleading. Endianess assumptions are based upon -D[LB]_ENDIAN macro in corresponding ./Configure line, not upon CPU macros set up by compiler. Well, assembler code does assume endianess [naturally!], so that if you get rid of -D[LB]_ENDIAN [or change it], you better configure with no-asm. Also note that [LB]_ENDIAN is essentially a performance option and the code works correctly without it.
As it happens, I have a big-endian environment on an Intel box,
Is it really possible? Is there an x86 big-endian? Is it possible to switch Intel x86 to big-endian? What OS does it run? Which config line does OpenSSL picks then?
I presume that a PPC is a PowerPC, which is also a big-endian platform.
PowerPC processor is capable of operating in either mode, so that *formally* you can't assume endianess based solely on the fact that it's PowerPC-based. The switch is software initiated and is commonly performed by kernel bootstrap loader. Well, "commonly" is a bit misleading, because Windows NT and Solaris were the only ones I'm aware of [yes, there was NT for PPC and there was Solaris for PPC], which would switch to little-endian mode. Meaning that it's rather safe to assume that it's big-endian, as long as we're talking about a "commodity "platform, but not if we discuss some embedded one.
Take a close look at some of the #if macro tests in, for example, crypto/sha/sha_locl.h. You could be hitting a similar problem.
I bet not:-) As mentioned, it smells a compiler bug...
We found the problem by one of our programmers having a brilliant insight,
You could as well just stick to instructions in ./README to get rid of assembler and examine line in ./Configure to spot -DL_ENDIAN and realize it's not appropriate in your case. You didn't actually have to modify the source code. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
