64-bit iOS build

[Mike Ash]

Hello,

I'm trying to get a build of the WebRTC library set up so I can use it in an iOS app. I'm able to build 32-bit for armv7 using the script here:

http://ninjanetic.com/how-to-get-started-with-webrtc-and-ios-without-wasting-10-hours-of-your-life/

However, I'm having a tough time getting a 64-bit build to work. So far, I've tried:

1) Setting target_arch=arm64, which produces a host of undefined symbol errors, and produces some 32-bit libraries.

2) Adding target_subarch=64, which produces a bunch of errors when the compiler attempts to compile 32-bit inline assembly as 64-bit.

3) Both target_arch=arm64 and target_subarch=64, which looks superficially successful, but only produces a few output libraries that are woefully incomplete.

The "device" script from that site has an odd bit of corruption in the script where it refers to "build_with_libjinglth_chromium=0", which I replaced with "build_with_libjingle=1 build_with_chromium=0".

I also struggled for a while with setting GYP_GENERATORS=xcode to produce Xcode project files, then building using those files. I ran into various problems with the resulting files and wasn't able to get them to build cleanly at all.

I'm happy to provide any additional details if they're helpful. I didn't want to flood this message with thousands of lines of output before making sure my general approach is correct. If anyone could comment on the correct way to build these libraries for iOS ARM64, I would be most grateful.

Mike

[Zeke Chin]

GYP_GENERATORS=xcode is no longer supported and likely won't work.

What's the reason you need this for arm64? Afaik bunch of libraries won't be optimized to work in that environment (since they might be specifically optimized for armv7 instructions) so even if it can be built correctly it will likely be slow. 

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mike Ash]

Good to know about GYP_GENERATORS=xcode not being supported, that'll save me from trying it again if I get to that poitn.

I'm adding WebRTC-based functionality to an existing app that already builds ARM64. In general, it's good to have a 64-bit build on iOS, because being the only 32-bit app running incurs a substantial memory penalty as the only consumer of 32-bit frameworks. It's also likely that Apple will start requiring apps to have a 64-bit build before too long, and it would be good to be ready for that. In the worst case I can drop the 64-bit build of the app for a time, but it would be much better if I didn't have to.

Mike

[Andy Savage]

He's right.

By apples design apps that are 32bit cause apple to load both 64bit and 32bit core shared frameworks into memory. 

Whereas if the app is 64bit only, then there's only one set of frameworks in memory at one time.

Even if it wasn't optimised (yet) for 64bit, being able to compile as such automatically causes less memory usage.

As the previous poster mentions It also future proofs, which is a very big bonus.

--
Sent from Gmail Mobile

[Zeke Chin]

Not disputing the usefulness of supporting arm 64bit. Was just curious what Mike's particular use case was since as was mentioned 64bit isn't a requirement by Apple yet :)

Mike - I don't think there's an easy flag to get things compiling for 64bit iOS at the moment. As you saw, there's a bunch of assembly in the various libraries that get pulled in that works for 32bit but not 64bit arm. Unless each said library has fallback non-assembly 64bit compilable code + a flag to compile under fallback, this probably won't work right now. I don't know of an official ETA to support 64bit iOS but it's at least on the radar.

[Mike Ash]

I totally understand. Whenever somebody asks me how to do something that's hard and not necessarily required, my first thought is to ask why and make sure it's actually needed.

Thanks for the confirmation about the build process. Knowing (or at least being fairly sure) that it's not ready yet will at least keep me from beating my head against it too much more, and it lets me know that if I do want to go try it on my own, I'll have to depart the beaten path to some extent.

I would *hope* that all the relevant libraries would have non-assembly fallbacks, but I'm not surprised if they haven't been set up to go for the fallbacks in the case of "it's ARM, but not as we know it" yet. I'll proceed with 32-bit for now (I've made decent progress on it so far) and keep my eyes open for developments here.

Mike

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[sfa...@missing3.com]

Just to update this, it looks like this is coming relatively soon:

"Starting February 1, 2015, new iOS apps uploaded to the App Store must include 64-bit support..."

[jordi domenech flores]

hey! I managed to compile w/ no errors for iOS arm64. Also tested w/ my app, not AppRTCDemo but is using peerconnection API (well, a patched version for my needs). 

this is something :)

the cpu usage is higher on avg: 50-60% on an iPad mini retina vs 40-50% on iPhone 5. built in release mode, and video is captured w/ CIF quality, but cropped to 320x240 before encoding, also w/out orientation correction since after some tests I saw it seems to consume more cpu. As you see in the patches I'm attaching, I removed the 'assembly optimization stuff', more or less. Also, only a compilation error occurred, but was easily solved.

gyp env:

export GYP_GENERATORS="ninja"

export GYP_DEFINES="OS=ios target_arch=arm64 target_subarch=arm64 build_neon=0 $GYP_DEFINES"

export GYP_GENERATOR_FLAGS="$GYP_GENERATOR_FLAGS output_dir=out_arm64"

export GYP_CROSSCOMPILE=1

then 

gclient runhooks

then

ninja -C trunk/out_arm64/Release-iphoneos AppRTCDemo

My workflow is: 

- build for each arch 

- for each arch, libtool to 'join' the bunch of static libs, then strip to reduce size

- lipo to make a fat lib from the previous stripped static libs

I synched my repo w/ webrtc trunk a week ago, maybe thursday. If some patch fails, maybe that is the reason.

hope it helps, but anyway it seems good news, at least for me!

[Alexandre GOUAILLARD]

great work,

so, it compiles and work, but you likely fall back to C/C++ (and not assembly) so it's slower and/or takes more resources. It's consistent with the info that were provided before on that list.

What would be interesting (moving forward) would be to identify which part of the code fall back to higher level code instead of assembly when switching to 64bits and slowing port them all. We could wait of google to do it, or we could try to make it happen faster by sharing the work. As mentioned before, it's likely that some of the 15~20 external libs have such problem as well.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[aaroncray]

I haven't verified but if it works kings you to man! Thank you for posting the patch!

[I Ainx]

FWIW it seems that libyuv now has an arm64 version and the libyuv patch isn't needed anymore.

[jordi domenech flores]

the mediachannel patch is no longer necessary, as webrtc team has solved that!

I've been trying other things, just for fun, so attaching an alternative libvpx patch that also works. we're living on the edge :)

[Scott Wang]

Thanks a lot for your work!

I've written a Makefile to build a universal framework for i386, x86_64, armv7, and arm64

You can clone this repository: 

https://github.com/lunastorm/webrtc-ios

and run make -j4

It takes about 40 minutes on my MBP 13" to build the framework (including time to sync the repositories)

A file named WebRTC.framework will be generated in the directory.

Tested on 32 and 64bit ios simulators, iPad Air, iPhone 6+ :)

-Scott

[Josip Bernat]

Thanks for your script but I receive some errors every time I try to run it. Do I need to install some special packages before running the script?

I have command line tools already installed.

Thanks,

Josip

[tech74]

Hi, 

I tried building latest sources with this 

export GYP_DEFINES="$GYP_DEFINES OS=ios target_arch=arm64 "

but it doesn't build 64bit libs. Is 64bit supported for ios yet?

Thanks

[Ingo Liebig]

Any news on this?

I tried building a 64bit version for iOS ...I couldn't get it to work yet.

Did anybody manage to get this to work?

[Zeke Chin]

You can star:

https://code.google.com/p/webrtc/issues/detail?id=3898

TL;DR

libvpx.gyo had an obsolete target dependency in 64bit. If you remove that dependency everything should build for 64bit. It's been updated in chromium and will be present in webrtc on the next chromium roll.

--

[Maxim Potapov]

3898 is resolved and working fine for devices (arm7, arm64). Does anybody have a success with a x64 simulator? (x86_64)

среда, 3 декабря 2014 г., 22:55:22 UTC+3 пользователь Zeke Chin написал:

[Caragea Silviu]

I succedd to compile everything fine on all devices with last version.

For simulator on 64 bits use target_arch=x64 target_subarch=arm64

[Maxim Potapov]

Thanks! Compiled everything too.

суббота, 13 декабря 2014 г., 12:31:22 UTC+3 пользователь silviu.cpp написал:

[Rahul Pathak]

Hi all, 

   I am getting error on WebRTC build for arm64 Device. 

- I got an error. 
    [6/1989] CXX obj/webrtc/modules/audio_coding/codecs/audio_encoder_interface.audio_encoder.o
FAILED: c++ -MMD -MF obj/webrtc/modules/audio_coding/codecs/audio_encoder_interface.audio_encoder.o.d -DV8_DEPRECATION_WARNINGS -DDISABLE_NACL -DCHROMIUM_BUILD -DCR_CLANG_REVISION=218707 -DUSE_LIBJPEG_TURBO=1 -DENABLE_CONFIGURATION_POLICY -DDISCARDABLE_MEMORY_ALWAYS_SUPPORTED_NATIVELY -DSYSTEM_NATIVELY_SIGNALS_MEMORY_PRESSURE -DDONT_EMBED_BUILD_METADATA -DCLD_VERSION=2 -DDISABLE_FTP_SUPPORT=1 -DENABLE_LOAD_COMPLETION_HACKS=1 -DWEBRTC_RESTRICT_LOGGING -DEXPAT_RELATIVE_PATH -DWEBRTC_MODULE_UTILITY_VIDEO -DWEBRTC_ARCH_ARM -DWEBRTC_ARCH_ARM64_NEON -DWEBRTC_POSIX -DWEBRTC_MAC -DWEBRTC_IOS -DUSE_LIBPCI=1 -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0 -DNS_BLOCK_ASSERTIONS=1 -D_FORTIFY_SOURCE=2 -Igen -I../.. -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.1.sdk -Os -gdwarf-2 -fvisibility=hidden -Werror -Wnewline-eof -miphoneos-version-min=7.0 -arch arm64 -Wall -Wendif-labels -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wno-selector-type-mismatch -Wno-unknown-warning-option -Wheader-hygiene -Wno-char-subscripts -Wno-unneeded-internal-declaration -Wno-covered-switch-default -Wstring-conversion -Wno-c++11-narrowing -Wno-deprecated-register -std=c++11 -stdlib=libc++ -fno-rtti -fno-exceptions -fvisibility-inlines-hidden -fno-threadsafe-statics -fcolor-diagnostics  -c ../../webrtc/modules/audio_coding/codecs/audio_encoder.cc -o obj/webrtc/modules/audio_coding/codecs/audio_encoder_interface.audio_encoder.o

I tried with revision - 7977.

Can anyone help for same?

[tech74]

Is it possible to build an armv7 and arm64 build as a fat build with build tools or is some more

work required to combine them?

Thanks

[Zeke Chin]

The short answer is no, more work is required (build armv7 / arm64 separately and lipo the results). Feel free to file a bug / submit a patch for a script / gyp target to do this.

The long answer is yes, but the various projects aren't set up to do it properly (Ideally each project should build correctly using target_arch=arm target_subarch=both, but this isn't true currently. Using target_subarch=both will compile both 32 and 64 and merge the results into fat libraries).

--