From: "Henri Gomez" <[EMAIL PROTECTED]>
Kurt Miller a écrit :
From: "Henri Gomez" <[EMAIL PROTECTED]>
It was u_long before I change it in in_addr_t and then change it back to u_long.
Oh. I guess I should have done a bit more research.;-) I just started attempting to get mod_jk going on sparc64 a few days ago. However, using
a
u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64.
The
memcpy at the end copies all zeros into rc->sin_addr when u_long is
used.
There are some other issues going on with mod_jk OpenBSD/sparc64, so its
not
yet working even with this corrected. Given that, it may not make sense
to
hold up the release for this. I will need to put in more time to
investigate
the next issue.
OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the
new
APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they
all
don't work. It wasn't until recently that I had time to start
investigating
it. I'll post patches here as I make progress.
The correct behaviour will be to use in_addr_t, but it don't works on iSeries (even if it's defined, I couldn't find the correct include).
To fix the problem we could use a #define BSD64 ? to make use of in_addr_t until we make more works ?
Just provide the correct defined var for BSD/SPARC64
I'm thinking a define may not be needed. I mischaracterized the problem slightly... u_long on OpenBSD/sparc64 is 8 bytes long, so the memcpy copies 8 bytes into rc->sin_addr. The first four bytes are zeros the next four overwrite some of the rest of the struct.
Would it fix the problem if laddr was defined as a datatype that is 4 bytes long on all arches? Maybe u_int32_t or struct in_addr (same as rc->sin_addr)?
Hum trying to play with bytes is not a good idea, we should stay with socket API and types.
BTW, the current code is not compatible with IPv6, and we may have to use APR supports API, which could break the consensus that JK should works without requiring APR (or Apache 2.0).
The future will be mod_jk2, and I think we should focus on it after the 1.2.5 release.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
