All,
some longer time ago I posted a patch to remove the BN_LLONG define for
NetWare CLIB builds. This was for two reasons: I could remove the
dependency on CodeWarrior's runtime library + I was able to build with
gcc where I had no CLIB-based runtime at all. I assumed that the
BN_LLONG define controls whether OpenSSL either uses 64-bit arith from
the OS, or some own replacements; and compilation went fine without
BN_LLONG defined.
Some time later I found that the bnllong test at least produced another
output as what I got with the LIBC builds where BN_LLONG is defined; but
unfortunately I was very short with time, and my mail account was busted
and even more worse I couldnt subscribe with my new account - so all
these things held me up looking further into it.
Now due to a couple of recent changes I see that currently all 3
branches HEAD, 1_0_0 and 0_9_8 are broken for NetWare, and one of these
breaks is that compilation for CLIB does no longer work without having
BN_LLONG defined with 0_9_8 branch:
d1_pkt.c: In function `dtls1_read_bytes':
d1_pkt.c:760: incompatible type for argument 3 of `dtls1_buffer_record'
make[1]: *** [d1_pkt.o] Error 1
though branches 1_0_0 and HEAD compile fine; I think because the
prototype is different:
static int dtls1_buffer_record(SSL *s, record_pqueue *q,
unsigned char *priority);
while with 0_9_8 we have:
static int dtls1_buffer_record(SSL *s, record_pqueue *q,
PQ_64BIT priority);
line 760 / 0_9_8 and line 803 / 1_0_0 and HEAD is:
dtls1_buffer_record(s, &(s->d1->buffered_app_data), 0);
maybe the prototype from 1_0_0/HEAD needs backported to 0_9_8 branch?
Then I would also like to get some clarification about the BN_LLONG
define, and if its valid to compile without this define for a 32-bit
platform?
thanks, Günter.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
