支持armv7和arm64的iOS webRTC库

Question

如何获得支持iOS中armv7和arm64的webRTC库？

Answer 1

You are lucky. I have just finished to integrate webrtc in my project for couple days. My solution as below:

1. Combine all *.a you built for armv7 to libWebRTC-armv7.a: Using command lines as below

   libtool -static -o src/out_ios_armv7/Release-iphoneos/libWebRTC-temp.a src/out_ios_armv7/Release-iphoneos/*.a

   strip -S -x -o src/out_ios_armv7/Release-iphoneos/libWebRTC-armv7.a -r src/out_ios_armv7/Release-iphoneos/libWebRTC-temp.a

2. Combine all *.a you built for arm64 to libWebRTC-arm64.a:

   libtool -static -o src/out_ios/Release-iphoneos/libWebRTC-temp.a src/out_ios/Release-iphoneos/*.a

   strip -S -x -o src/out_ios/Release-iphoneos/libWebRTC-arm64.a -r src/out_ios/Release-iphoneos/libWebRTC-temp.a

3. Create your libWebRTC supported both armv7 and arm64:

   lipo -create src/out_ios_armv7/Release-iphoneos/libWebRTC-armv7.a src/out_ios/Release-iphoneos/libWebRTC-arm64.a -output libWebRTC.a

Ps: Just build your armv7 library to separated folder with arm64:

export GYP_GENERATORS="ninja"
export GYP_DEFINES="build_with_libjingle=1 build_with_chromium=0 libjingle_objc=1 OS=ios target_arch=armv7"
export GYP_GENERATOR_FLAGS="$GYP_GENERATOR_FLAGS output_dir=out_ios_armv7"
export GYP_CROSSCOMPILE=1
pushd src
gclient runhooks
ninja -C out_ios_armv7/Release-iphoneos AppRTCDemo
popd

Answer 2

You can refer to our blog:

http://io.diveinedu.com/2015/02/02/%E7%AC%AC%E4%BA%94%E7%AB%A0-WebRTC%E7%9A%84iOS%E6%A1%86%E6%9E%B6%E7%BC%96%E8%AF%91.html

I have wrote a shell script to build WebRTC sources to a framework(excluding the apprtc signaling library) for iOS use.

If you cann't read Chinese, you just read that script embedded in that blog, it's enough! aha.

./build_webrtc.sh build_all

There may be a bug in armv7 device. that bug was caused by a stack over flow issue in VP8 decoding in armv7 neon function.

You can confirm this patch to fixes crash for it:

diff --git a/source/libvpx/vp8/common/arm/neon/vp8_subpixelvariance_neon.c b/source/libvpx/vp8/common/arm/neon/vp8_subpixelvariance_neon.c
index 8308d55..a66b6f5 100644
--- a/source/libvpx/vp8/common/arm/neon/vp8_subpixelvariance_neon.c
+++ b/source/libvpx/vp8/common/arm/neon/vp8_subpixelvariance_neon.c
@@ -1003,7 +1003,7 @@ unsigned int vp8_sub_pixel_variance8x8_neon(
         const unsigned char *dst,
         int dst_stride,
         unsigned int *sse) {
-  DECLARE_ALIGNED_ARRAY(kAlign16, uint8_t, temp2, kHeight8 * kWidth8);
+  DECLARE_ALIGNED_ARRAY(kAlign16, uint8_t, temp2, kHeight8PlusOne * kWidth8);
   DECLARE_ALIGNED_ARRAY(kAlign16, uint8_t, fdata3, kHeight8PlusOne * kWidth8);
   if (xoffset == 0) {
     var_filter_block2d_bil_w8(src, temp2, src_stride, kWidth8, kHeight8,

Wish this can help you!

The students of diveinedu.com have just overcome and fixed this bug.

Answer 3

thanks phuongle, this really works...

...but with a twist...

...as Omer Waqas Khan noticed, there might be a case where one might encounter the error message (while lipo-ing): both libs can't be of the same structure .

Of course, I went WTF...lipo, what's wrong with you...they are of different structure...I BUILT THEM THAT WAY...

But then I set out to double check it:
- I went in the folder where I had the arm64_merged lib and...

lipo -info lib's_name.a

It reported back of being of both armv7 and arm64 type. Puzzled, I then...

lipo -info *.a

...all the libraries (72 of them) reported being of type arm64 except for 2...

libisac_fix.a
libisac_neon.a

For whatever reason they were armv7. Earlier in the day, I was using a "a few days old" clone of the webrtc thingy. Back then, I remember always obtaining only 70 libraries. But then, for other reasons, I decided to

gclient sync

After that, I ended up with 72...as such, I just removed the libisac nonsense. Now the 2 fat_libs were of different types and I could successfully lipo.