From: "Henri Gomez" <[EMAIL PROTECTED]> > Kurt Miller a écrit : > > > 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. >
Ok. I jumped in on this thread because I thought that a new problem was introduced, but that is how it was in prior releases. I can report 1.2.5 works fine on OpenBSD-current/i386. I will keep working on OpenBSD/sparc64 and post patches here when it is working. If there's a 1.2.6 release maybe they can be incorporated then. -Kurt --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
