From what I've read, the iPhone 5 will use a new architecture, armv7s. My project had valid architectures as armv7, and had Build Active Architecture Only set to true. Since every app in the store right now is built for armv6 and/or armv7, I can't imagine that it will not run on the new iPhone. So what occurs? Does it just not run as well as it could?
I could just use a better explanation of what is occurring, and what would be different once I rebuild and submit with armv7s as a valid architecture.
First, it's armv7, not arm7 (yes, there is a difference). I can't seem to find any docs on the specifics, but I imagine armv7s adds support for some optional ARMv7 features, e.g. VFPv4/FMA, or UDIV/SDIV integer division instructions. I can't imagine the difference will be noticeable unless your app deals with a lot of math or graphics.
Edit: see this link for the changes made to LLVM for armv7s support. From what I see, it's indeed just VFPv4 and integer divide, plus some changes to the instruction scheduler. Apparently the CPU codename is "Swift".
Related
Currently our Xamarin Android app (PCL) is huge in my opinion, even in release mode. I suspect it is due to supported architectures. Currently we have them all selected. Does anyone know if we have to select all of these? We are not using the Android NDK at all as well.
I will copy part of my answer from here.
Make sure you are at least checking the following architectures: armeabi-v7a and x86. You could do the other three but we do not since we use LLVM compiling in release mode, which is not compatible with the 64 bit architectures (except for armeabi, which is deprecated). The good thing about that is that all of the 64 bit architectures can still use 32 bit builds so they all still get covered if you check those 3.
So I would just check those 3 unless you have a specific reason to check the other ones. We have had 0 problems installing our app on devices using those 3 only.
On a side note, turning on LLVM compiling and optimizing your icons/images will help with the final APK size.
*Edit: Since writing this we ran into a bug only on certain devices (Android Nexus 9) which leads to app crashes when launching the app. The solution is to check the arm64-v8a architecture. This will probably increase app size so weigh the pros and cons and see how much of a difference it makes in your APK size after including the architecture or split your APK for each architecture if necessary.
No you do not have to select all of them. You can create an .apk per ABI if you wanted to to reduce the size of your .apk. Note: The encouraged method is that you develop and publish a single .apk. However this is not always practical, and sometimes it's better to create separate ones. Although this answer only goes into depth about different CPU Architectures (ABI), you could also create different .apk for screen size, device features, and API levels.
https://developer.xamarin.com/guides/android/advanced_topics/build-abi-specific-apks/
http://developer.android.com/google/play/publishing/multiple-apks.html
I would recommend grabbing a tool like WinDirStat(https://windirstat.info/) or Disk Inventory X(http://www.derlien.com/) to investigate why your .apk is so large. You might find other reasons why your .apk is large such as resources(images, raw files), assemblies, etc.
I checked the table from the following page, if I remove "armv6" from Valid Architectures of Xcode, does it mean the app would fail to run on the iPhone1, 3G and iPod touch 1st, 2nd?? Is that so simple?
Anything else would be affected?
My game is Coco2ds-x
http://en.wikipedia.org/wiki/List_of_iOS_devices
Yes, you'll be safe removing the ARMv6 architecture from your project if you don't need to support those ancient devices - ARMv7 and later will let your app run on:
iPhone 3GS and later
All iPads, 'normal' and mini
iPod Touch 3rd generation and later
I got most of this from Apple's iOS Device Compatibility Reference, which is an awesome resource.
In fact, Xcode 4.5 and later doesn't know how to build for the ARMv6 architecture. This is, in my opinion, a gentle nudge to developers to stop supporting old platforms, and instead keep up with what's new so they can make newer, faster, better apps.
I would like to know the difference between those architectures in Xcode because I need to know how I understand that a library can compile correctly for iOS Simulator and also for iPhone 5, iPhone 4s and iPhone 4. Or just for one of those.
i386: Typically MacOSX (I am not sure whether Simulator is included here or no).
arm6: old iPhones.
arm7: iPhone4/4S.
arm7s: additional instructions for arm7 to make good use of iPhone 5 processor.
Hope this helps. Compiling libraries to support all platforms sometimes is very frustrating and tedious task. Good luck!
I intend to cross compile for Raspberry Pi, basically a small ARM computer. The host will be an i686 box running Arch Linux.
My first instinct is to use cross compiler provided by Arch Linux, arm-elf-gcc-base and arm-elf-binutils. However, every wiki and post I read seems to use some version of custom gcc build. They seem to spend significant time on cooking their own gcc. Problem is that they never say WHY it is important to use their gcc over another.
Can stock distro provided cross compilers be used for building Raspberry Pi or ARM in general kernels and apps?
Is it necessary to have multiple compilers for ARM architecture? If so, why, since single gcc can support all x86 variants?
If 2), then how can I deduce what target subset is supported by a particular version of gcc?
More general question, what general use cases call for custom gcc build?
Please be as technical as you can, I'd like to know WHY as well as how.
When developers talk about building software (cross compiling) for a different machine (target) compared to their own (host) they use the term toolchain to describe the set of tools necessary to build binary files. That's because when you need to build an executable binary, you need more than a compiler.
You need routines (crt0.o) to initialize runtime according to requirements of operating system and standard libraries. You need standard set of libraries and those libraries need to be aware of the kernel on target because of the system calls API and several os level configurations (f.e. page size) and data structures (f.e. time structures).
On the hardware side, there are different set of ARM architectures. Architectures can be backward compatible but a toolchain by nature is binary and targeted for a specific architecture. You can have the most widespread architecture by default but then that won't be too fruitful for an already constraint environment (embedded device). If you have the latest architecture, then it won't be useful for older architecture based targets.
When you build a binary on your host for your host, compiler can look up all the necessary bits from its own environment or use what's on the host - so most of the above details are invisible to developer. However when you build for a different target than your host type, toolchain must know about hardware, os and standard library details. The way you tell these to toolchain is... by building it according to those details which might require some level of bootstrapping. (or you can do this via extensive set of parameters if toolchain supports / built for it.)
So when there is a generic (stock) cross compile toolchain, it has already some target specifics set and that might not meet your requirements. Please see this recent question about the situation on Ubuntu for an example.
In iOS5 Apple drops the armv6 architecture from the ARCHS_STANDARD_32_BIT.
In order to keep the support for iPhone3G I still want to compile in armv6 even in iOS5.
Did anyone find a solution for this?
I just built something today specifying a deployment target of iOS 4.0. With only armv7 specified in Architectures, Xcode warned me that to support anything below iOS4.2 I had to include armv6 in Architectures. Just edit that field, click the "+" button when the dialog pops up and enter the literal "armv6".
In my case, we want our app to work under iOS4 and iOS5. We had to make some modifications so it would work correctly under iOS5, but all those changes were done with iOS4-friendly code changes.
We also added some iOS5-specific capabilities in a manner that allows the app to run without crashing under iOS4. Specifically, we tested for iOS5 capabilities before trying to use them, and linked iOS5-only libraries as Optional.
So, supporting iPhone3G in an iOS5 world could just as easily mean "we want our app to run on iOS4 and above (regardless of any iOS5 feature use)" rather than "we want to make sure our app runs on an older device running iOS5". There's a difference here; think about it. :-)
Anyway, adding armv6 support back in is very easy. And I guess the point is this: At some point, when there are no more armv6 devices out there to worry about (for whatever reason) you won't have to build for it. Apple's view is everyone should upgrade to the latest hardware as soon as possible. So in that world, there is no need for the tools to default to anything but the latest and greatest too. :-) Fortunately (or not), we developers live in the real world and recognize that you have to support older stuff for a while. And I guess the Xcode dev team knows this too, which is why you can add armv6 support back in quite simply.
The simple answer is that you have to change the current settings from "Standard (armv7) - $(ARCHS_STANDARD_32_BIT)" to just be "armv6" and "armv7". See the image below. You have to delete the line with the previous settings for it to work.
also make sure you set this in Project AND Targets ... cost me an hour to figure that out. had set it for one but not the other. hope this helps. GLTA
I think there's a reason why Apple dropped armv6 from the standard setting.
I have compiled armv7/armv6 with iOS5 SDK, however, the armv6 compiler produced wrong code in release mode. After hours of finding a workaround (trying llvm or gcc with different optimization levels) I give up.
So, I am going back to iOS SDK 4.x as long as I support older armv6 devices.
Example of code:
// myView center=(160, 100)
CGPoint p=myView.center;
// now p=(100,100) (what the heck?)
p.x=myView.center.x;
p.y=myView.center.y;
// now p=(160,100)
p.y+=100;
// now p =(200,200) (what the heck?)
Maybe I'm have some memory corruption, however, on the armv7 compiler and on iOSSDK < 5.0 it behaves as expected.
Best regards
Not sure if this is actually a solution yet, but I have discovered that replacing the defined string in "architectures", which was $(ARCHS_STANDARD_32_BIT), with "armv6 armv7" allowed me to compile with iOS5 as a base and iOS4 as a deployment target, and pass validation .
I am not using any IOS5-exclusive libraries or calls, but intend to in my next release.
I did not need to replace $(ARCHS_STANDARD_32_BIT) with just armv7 for the app to compile and be uploaded to the App Store.
As suggested by MarkGranoff, I simply added armv6 as plain text, by hitting plus and just typing it in on line two.