> >> > BN_div_recp failed!
> >> > a=21CC27865629353755638C3726DF4C2D1C976729D1CD3C3FFC01039CE01B6687959E2BB84BAB54
> >> > D798D9873CAED7007AB955B025F799BDE5AE4C84D79DE7B35E7ED2A43
> >> > b=1
> >>
> >> > d:\net\openssl.095\bin>openssl.exe version -a
> >> > OpenSSL 0.9.5beta2-dev 28 Feb 2000
> >>
> >> -DBN_DEBUG
> > ^^^^^^^^^ But I wonder how did you get through the compilation? There
> >is a typo in crypto/bn/bn_asm.c in 0.9.5beta2 triggered by -DBN_DEBUG.
> >If you've never discovered the typo, then it means only one thing, you
> >link with assembler module...
>
> Thats right, I do.
>
> > Which assumes bn(64,32) option...
>
> Why it that?
Because that's the way it's hand-coded in assembler.
> What's the CFLAGS and other configure options for if
> the PerlAsm modules have to assume anything.
perlasm is hired to hide behind curtains syntax differences between
different assemblers, e.g. GNU as vs. MASM, and it doesn't pay no
attention to CFLAGS. But as I already said
>
> > Well, shouldn't really matter... At least I can't imagine it would...
>
> Notice how BN_LLONG doesn't give me "bn(64,32)". I assume it's because
> I don't have a correct ./opensslconf.h.
Yes, BN_LLONG must be defined in opensslconf.h, never in command line.
>
> But, most important, the divtest program doesn't give any errors now ?!!
> The error, I forgot to say, only occurs in a DOS-box under Win-NT4 (SP3).
Extremely weird... I mean I can understand if nothing would work in a
DOS-box... I mean what's so special about divtest?
>
> BTW. One more compile error; defining BN_LLONG requires
> -DHAVE_LONG_LONG=1 or parse error is produced in
> ./crypto/bio/b_print.c (line 128).
Again, BN_LLONG must be defined in opensslconf.h, never in command line.
Andy.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
