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)? -Kurt --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
