On 13.02.2009, at 18:40, Ruud Klaver wrote: > 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 > > <pjsip-2451-osx_unified_binary_endianness_fix.patch> Hi Ruud, Have you tested the sound of the patched version on PPC? One of the users of my app reports that it didn't solve the distorted sound problem. Alexei
