tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kurt Miller" <>
Subject Re: [VOTE] Release mod_jk 1.2.5
Date Fri, 01 Aug 2003 14:49:55 GMT
From: "Henri Gomez" <>
> Kurt Miller a écrit :
> > From: "Henri Gomez" <>
> >
> >>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
> > u_long for laddr is the cause of jk_resolve failing on OpenBSD/sparc64.
> > memcpy at the end copies all zeros into rc->sin_addr when u_long is
> >
> > There are some other issues going on with mod_jk OpenBSD/sparc64, so its
> > yet working even with this corrected. Given that, it may not make sense
> > hold up the release for this. I will need to put in more time to
> > the next issue.
> >
> > OpenBSD-3.3/sparc64 uses Apache 1.3.27 so this is not an issue with the
> > APR code. I tested releases 1.2.1 - 1.2.5 on OpenBSD/sparc64 and they
> > don't work. It wasn't until recently that I had time to start
> > 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


View raw message