On Fri, Feb 13, 2009 at 3:40 PM, Ruud Klaver <ruud at ag-projects.com> wrote: > > I've included a patch that, in the case of OS-X, ignores this value set by > configure and replaces it by the value gcc provides (__BIG_ENDIAN__). When > setting the "-arch ppc -arch i386" flags, it will automatically set the > right endianness for the architecture it is compiling for. It would have > been cleaner to use the universal-binary option that the endianness > detection in autoconf actually provides, but I couldn't figure out how to > use it. > > I've tested this by compiling on i368 and copying the result to ppc. My > client works now, including registration and functioning audio. I haven't > actually tested the pjsua binary. When running the pjlib-util test binary, > it seems that the crc32 implementation is not working, but as far as I can > see this isn't actually used by any of the upper layers of the PJSIP stack. > For some reason it doesn't like the table-based implementation, if I set > PJ_CRC32_HAS_TABLES to 0 it does work. I expected SRTP to also not work, > since parts of this also seem to be table-based, but I had no problems using > this on my test machine. > > Thanks for the patch Ruud. The crc32 is used only by STUN related things I think (so this includes TURN and ICE), and there are two sets of tables for each endianness. I assume the table based crc32 implementation works fine when the library is built natively? If it doesn't then probably the table is wrong, but if it does then I don't know why. Unfortunately I no longer have big endian machines here to test. A friend borrowed my ppc Mac and haven't return it (I should have known better!), and another is frozen, literally: http://www.facebook.com/photo.php?pid=30279808&l=75ec5&id=1267406476 :) cheers Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090213/94eff92a/attachment.html>
