second send - In my first send I included two script files logging the running of the make test as attachments, which were rejected, so resending without the attachments.
I rebooted the box, a IBM 44 Model 170 with a "PowerPC_POWER3" CPU with "realmem 2097152", just to make sure there was nothing else affecting the compile. I then recompiled using the "./config" with no flags. I then ran the "make test" and it got into an endless loop (attachment maketest3.script) I then set the environmental flag ( export OPENSSL_ppccap=0 ) as suggested and ran the "make test" again. (attachment maketest.script). This time the test ran to completion with "ALL TESTS SUCCESSFUL" dean On 05/13/2012 03:22 AM, Andy Polyakov via RT wrote: >> I originally thought my problem was with ssh, so that is what I was >> looking it, after I finally found that the problem was with the ssl, I >> sent the email to you. After that I did some more testing and found >> that by using the no-asm flag during the config everything worked normally. >> >> I guess my point is that the ssl version 1.0.0h didn't exhibit the >> problem, a change in between the 1.0.0h and 1.0.1b did, So at this >> point I was just wanting to make you aware of the problem because I >> haven't had any problems with building openssl in quite some time. > If "just making you aware" was the sole purpose, then it's not good > enough. In sense that if you have no intention to follow up, then > nothing will be done about the problem. Because I can't reproduce the > problem, not with 'make test' in 32-bit build. Though I didn't test on > AIX 5.2 nor your specific CPU [which I don't even know what it is]. > > Considering that no-asm does the trick, the only difference in PPC asm > between 1.0.0 and 1.0.1 is that ppc64-mont.pl is used even in 32-bit > build. Code from ppc64-mont.pl is engaged on CPUs capable of executing > fcfid instruction. The instruction was introduced later and is not > available on processors uncapable of executing integer 64-bit code. > However, the instruction itself is floating point and is perfectly > usable in 32-bit context. If kernel tries to be nice by emulating it, it > can lead OpenSSL to wrong conclusions. To verify if this might be the > case run 'make test' with OPENSSL_ppccap environment variable set to 0, > e.g. 'env OPENSSL_ppccap=0 make test'. > > >
<<inline: DCarter.vcf>>
