I have an SDK that I'm trying to compile and I was wondering what happens when I choose the Standard Architectures (armv7, armv7s) option under "Architectures"?
It is my understanding that the armv7 instruction set can run on devices that support armv7s as well but not the other way around. So when I compile with this option is the compiler outputting a binary with two SDKs, each using a different instruction set or just one with armv7?
I'm confused and not sure if I'm thinking about this correctly.
Yes, if you specify both armv7 and armv7s, it builds a "fat binary" containing two sets of object code, one targeted for armv7 and the other for armv7s. When the app is installed on a phone, the installer uses the correct object code for the device it is installed on.
You could specify just "armv7" and, you are correct, the generated object code will run on both an armv7 and an armv7s. However, it will run slower on the armv7s than a binary containing both sets of code.
In general, unless you have a specific reason for not doing it, stick with "Standard Architecture", since that provides the best support for the currently supported iOS devices.
Related
xcodebuild can build a project with sdk set to either iphoneos or iphonesimulator but not both, so in order to generate a framework containing armv7 arm64 and i386 x86_64 architectures, I have to run xcodebuild twice and then use lipo to combine all the architectures into 1 universal binary. I see commercial framework that does this but it result in an incorrect info.plist file because it has a field, CFBundleSupportedPlatforms and all signs point to it only containing 1 value, e.g., CFBundleSupportedPlatforms = ( "iPhoneSimulator" ).
Seems like lipo shouldn't be used in this manner because it isn't officially supported by xcodebuld. Is there a better way to build a framework to contain all architectures?
I follow the question, but I suppose I am a bit puzzled why you want to unnecessarily bloat a single .framework with simulator-only i386 and x84_64 slices that are really only relevant to your development builds. Would you by chance be wanting to distribute a framework to other developers and want to make it work on simulator as well as device?
If so, you are on the right track with using lipo to join the thin binaries for device together or to join the thin binaries for simulator together, but shouldn't be trying to spawn one single device and simulator framework. Apple's own use of SDKs and Frameworks serves as the guide here. Within Xcode, there are two different platform SDKs -- iPhoneOS.platform and iPhoneSimulator.platform that contain the SDKs with only the slices for the relevant target architectures:
You can drill into each of these folders and find the UIKit frameworks do indeed follow the per-platform idea and are conditionally linked based on the SDK that is in use:
I'd further guess that you wanted to have one universal, all-architectures framework so that consuming developers didn't have to remember to swap out one .framework file for another depending on how they were compiling the app. The great news is that you can use conditional linking flags to be able to affect this without needing to do file-system swaps!
As folks adopt your library, part of the setup should be to use conditional linking -- Within the OTHER_LINKER_FLAGS option you can have per-configuration (Debug, Release, Ad-Hoc, etc.) build settings and can also have per-Architecture or per-SDK specific settings too:
To get access to these SDK-specific settings you'll need to click the + next to each of your build configurations where you want to custom tailor framework linking. You can then select the appropriate SDKs from the dropdown list and add your linker flags for each of the two target frameworks.
I'm trying to unzip .zip files on iOS.
I tried ZipArchive but got lots of linking warnings about undefined architectures for arm64.
I suppose I could remove the arm64 architecture from XCode, but Apple must have started including it in iOS Xcode project templates by default for a reason, and I don't know enough about the ins and outs of that so don't particularly want to remove it in case it causes headaches in the future.
So I tried ZZipArchive which builds and runs but was failing to open the file, which when I traced through the code I found the failing function was called ZOPEN64(). Surprise surprise it has 64 in its name, can't be a coincidence.
I don't see the point in trying another iOS unzip library as they all seem to be wrappers around minizip etc. and thus will have the same fundamental issues.
Is anybody using an unzip library with iOS 7 AND the latest XCode beta?
What are the consequences of removing the arm64 architecture out of the project if that's the only way for now to get unzip up and running?
To answer your question, the ramifications of removing arm64 from the architectures is that some classes of application will perform slower on devices with 64-bit capable processors (right now just iPhone 5s) than they would with arm64 builds enabled.
Note: at this point arm64 is required for all applications.
My project started doing something odd. I can build and test OK, but when I archive I get:
Warning all apps should include an armv7 architecture
In Target build settings I have Architectures set as $(ARCHS_STANDARD) and Base SDK as Latest iOS with Valid Architectures set as arm64 armv7 armv7s
I googled this and found several solutions saying to go to Target>Build Settings>Build Active Architecture Only and set that to NO.
Doing that, the project will no longer build and I get:
CCDirectorIOS.h Semantic issue
Redefinition of '__ccContentScaleFactor' with a different type:
'CGFloat' (aka double) vs 'float'
I'm quite a way through with this project and this is the first time I've had this problem. I've tried restoring from an earlier good backup and I get the same problem so presumably this has been caused by an Xcode update, and not by my own code.
Any suggestions?
Solution is simple, Change CGFloat to float
extern float __ccContentScaleFactor;
Here is discussion about Cocos2d 64 bit support
I have a fat (armv7 + i386) library I use for development now. Works fine but now I am concerned if Xcode will strip other architectures (i386) and other configurations (Debug for example) when building for release?
I don't plan to debug this library since it is very old and stable. I just want to use it so I guess I don't need all debug symbols (?), furthermore when building for release I won't even need the i386 since that is for the simulator.
Do I need to set up something in Xcode so it gets stripped or I should better be using a non-fat library? If so how can I control this? :)
This library is about 500KB so I prefer not to put more info than I need.
The library stores separate object files for different architectures (i386, armv7, armv7s etc.). When you build the final app, it will only retrieve the required architectures and only the required object files from the library. The final version for the App Store will certainly not contain any i386.
Regarding release and debug configuration, it's different. This concept is not known by the library tool. So it cannot store separate debug and release versions. And when building the app, it will take whatever it finds. So to minimize your final app, you'll need to build both the library and the app with release settings.
As many of you noticed; zxing does not work in latest xcode (4.5/ios 6)
Here is use case:
checkout latest version from trunk (as some fixes were already added)
create single view application in xcode 4.5 with ios 6.0
use README to add dependencies, paths etc (just follow step by step)
add zxingcontroller call to class (renamed to mm)
Compilation fails both for simulator and device
It shows 31 error like this one:
Undefined symbols for architecture i386:
"std::string::c_str() const", referenced from
all 31 errors are similar, difference is in symbols name
May be somebody knows how to solve it with this use case?
p.s. if you have app from previous Xcode, it works. Problem is only if you create new app in Xcode 4.5
The issue you have encountered seems to be C++ standard library related.
Actually, whenever you see linker failures in relationship with standard library objects (e.g. std::string), you should check the project settings on all linked libraries and the app-project itself. They usually need to match!
The original ScanTest (which builds ZXingWidget as a subproject) uses the following settings and those need to match your App build-settings if you use the library as is.
For making sure, I created a brand-new project using Xcode 4.5. That project uses ZXingWidget as a prebuilt library but not as a subproject - I dont like subprojects for stuff that is not my own - though this specialty wont influence the results.
The important setting is C++ Standard Library - make sure that is set towards Compiler Default
Little clarification
Actually, you do not need to use C++ Standard Library, you may as well use LLVM C++ standard library with C++11 support. But you will have to use that exact same library in all projects, sub-projects and libraries that link with your project. So if you insist on using the more recent version of that library (C++11 support), then you will have to build the ZXing library with those settings as well.
Last but not least, make sure your Architectures and Valid Architecture settings are matching over all projects and sub projects (fixing the common armv7s linker issue).
First, make sure your Architectures setting is set towards armv7 armv7s within all projects. Then also edit the project settings of all projects towards Valid Architecture armv7s armv7.
You might also want to switch the "Other Warning Flag" -Werror off. Seems to be necessary in Xcode versions > 4.5 (LLVM compiler > 4.1).
It works for me, have you enabled -lstdc++ in your list of Other Linker Flags in the Build Settings tab of the project target? It sounds like it is not recognizing the c++ symbols needed for zXing to build. If this is the case, the above advice should help.