Hi Alexei, On 01 Feb 2009, at 19:16, Alexei Kuznetsov wrote: > On 30.01.2009, at 18:53, Ruud Klaver wrote: > >> Hi Alexei, >> >> On 30 Jan 2009, at 01:45, Alexei Kuznetsov wrote: >> >>> On Tue, Jan 27, 2009 at 12:14 PM, Ruud Klaver <ruud at ag- >>> projects.com> wrote: >>>> This is what I've been doing to make a universal binary on i386 >>>> OS X: >>>> >>>> CFLAGS="-arch ppc -arch i386" ./configure >>>> make >>>> >>>> Could you confirm that this works on PPC? Or do you want to >>>> compile for 1 >>>> specific architecture only? >>> >>> Unfortunately, I can confirm some problems with such build. One of >>> the >>> users that has a PPC Mac could not register on the server because of >>> auth failure. So coudn't I running that build on an Intel Mac with >>> Rosetta. >>> >>> Alexei >> >> That's interesting, because I heard the same report from someone >> else. >> >> Were you successful in building a PPC binary when cross-compiling, >> and if so, could it actually register? >> >> Ruud Klaver >> AG Projects > > Not exactly. I've cross-compiled ppc binaries that were able to > register. But the user complained that sound was distorted inspite > of the fact that it was good on my Intel Mac in Rosetta emulation. > And when he builds pjproject natively, everything is fine. > > That distorted sound build had been made by me with the following > steps. > > $ ln -s /usr/bin/powerpc-apple-darwin9-gcc-4.0.1 /usr/bin/powerpc- > apple-darwin9-gcc > $ ln -s /usr/bin/ar /usr/bin/powerpc-apple-darwin9-ar > $ ln -s /usr/bin/ranlib /usr/bin/powerpc-apple-darwin9-ranlib > > $ ./configure --host=powerpc-apple-darwin9 --build=powerpc > > Edit build/rules.mak. Change one line: > - $(RANLIB) $(LIB) > + $(RANLIB) -o $(LIB) $(OBJS) > > $ make dep > $ make > > Maybe this is some byte-ordering problem, since PowerPC is big- > endian and i386 is little-endian? Or maybe I'm cross-compiling it > incorrectly? > > Alexei I spent some time investigating and testing this and came up with the following result. It is an endianness issue. The configure script of of PJSIP detects the endianness of the target machine through some autoconf feature and edits one of the headers to match it. This value gets read in quite a number of places and code is compiled conditionally on it. 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. In summary, apply this patch and call: CFLAGS="-arch ppc -arch i386" ./configure make This should result in a working universal binary. Please let me know any test results. Ruud Klaver AG Projects -------------- next part -------------- A non-text attachment was scrubbed... Name: pjsip-2451-osx_unified_binary_endianness_fix.patch Type: application/octet-stream Size: 514 bytes Desc: not available URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20090213/3097fbd3/attachment.patch> -------------- next part --------------
