I'm trying to use the facebook-ios-sdk in an iPhone application. I followed the setup instructions and it works perfectly on the simulator, but I cannot get it to run on my actual device. I am using Xcode 4.3 and my deployment target is 3.1 (with ARC).
When I try to run the application on the device, it complains that it cannot link the facebook-ios-sdk since the statically linked library (as per suggestion when using ARC) does not support armv6? According to the facebook-ios-sdk page it does however support it.
Is there a different way to compile the linked lib than described on the facebook-ios-sdk page to include armv6?
Open facebook-ios-sdk.xcodeprodj, then in Build Settings -> Architectures add armv6.
Build/rebuild the static library via the included script:
./scripts/build_facebook_ios_sdk_static_lib.sh
The Library should now work with armv6 and armv7
In addition to what rogchap mentioned, is the value of Valid Architectures "armv6 armv7" in the Build Settings for your facebook-ios-sdk project?
And just to be sure, my Architectures setting reads as follows without the quotes:
"armv6 $(ARCHS_STANDARD_32_BIT)"
Another hint: check your info.plist file for the key 'required device capabilities' and make sure that there is no value like 'armv7'. That would exclude armv6 devices.
Related
I have a doubt, when we set target device and build a normal working project then it builds success, but same project when I change target to simulator OR Generic iOS Device then it fails. I have shared screen shot for error details when I build a working project on simulator. What's the reason behind this why same code builds + runs perfectly on iphone devices OR Generic iOS Device, On the other hand fails on simulator? Please note that, I have added already necessary Framework in my project. Any suggestion will be great. Thanks guys.
http://i.stack.imgur.com/CJTim.png
it means the supporting frameworks are missed
for _OBJC_CLASS_$_SKStoreProductViewController
add StoreKit framework
for _OBJC_CLASS_$_asidentifiermanager
add AdSupport.framework
for _OBJC_CLASS_$_CMMotionManager
add
CoreMotion.framework
Whenever you encounter such issue, I recommend on using the 'lipo' tool of Apple. you call it like this:
/usr/bin/lipo -i <path-to-libraray-file>.a
The response will be:
Architectures in the fat file: <the-lib>.a are: armv7 arm64
I guess that in your case, the library which provides the ASIdentifierManager will only show armv7 and arm64 which are required to run on real devices, but not i386 required for the simulator.
So the question is where this library is coming from. If you got it from a 3rd party, ask them to provide a 'fat' library which include all the required architectures, including one for i386
Your mac (simulator) running on i386 architecture. If you compile your static libraries for i386 as well you will be able to use them on the simulator.
Try adding "i386" to the "Valid Architectures"
I have so far used Google APIs Client Library for Objective-C by compiling the source files directly into my app (as described here). If I were to switch over to linking to the iOS static library (as also described here), how would this insure that the code works on different architectures?
For instance, if I follow the verbatim instruction I have to compile the static library by choosing a schema (GTLTouchStaticLib) and an architecture (e.g. iOS Simulator: iPhone 5). If I choose a simulator as architecture, file libGTLTouchStaticLib.a reports that the archive contains code for architectures i386 and x86_64. If I choose a physical iPhone 5 instead, file reports on architectures armv7 and arm64.
How do I ensure that the libGTLTouchStaticLib.a that I'm going to drag into my application project's Build Phases "Link Binary with Libraries" list (according to Google's instructions) contains all (not just some) of the architectures that might be encountered when my app goes life? I guess armv7 and arm64 is sufficient for an app that requires iOS 8, but I'd like to be sure.)
You have to combine the generated binaries using lipo command line tool.
The following tutorial about creating static library in iOS demonstrates use of lipo under section Universal Binaries
Urban Airship provides an iOS 8+ framework called AirshipKit.framework. Linking and embedding this framework works fine in both the simulator and device. However, when I go to archive the binary and validate it, iTunes Connect says the app contains code for unsupported architectures i386 and x86_64. How can I get Xcode to remove support for these architectures from the archived app?
Under Build Settings I have:
Architectures: Standard architectures (armv7, armv7s)
Build Active Architecture Only: Yes for debug, No for release
Supported Platforms: iOS
Valid Architectures: arm64 armv7 armv7s
You could use lipo to extract the arm code to a new file and submit that one, but it sounds like something is very wrong - you shouldn't need to do anything like this to submit, it might be a bug in Xcode. Which version are you using? Did any other settings in the build get changed (the text would be bold if the build setting is modified from the default)?
There is a new version of the Urban Airship SDK, 5.0.3
Are you still seeing this issue when building with the new Framework version?
I struggled with the same problem for a couple of days until I realized my own idiocy. My app is set to support 7.0+ and yet I still had the Airship.framework, which as the UA (Urban Airship) documentation strictly recommends, was only to be used for 8.0 +
I removed the framework and the validation came back success!
So if your app is inclusive of 7.0 or lower, then all you need is the libUAirship-5+ library. As #aschuman suggested, there is a new one available (libUAirship-5.0.3.a)
I'm getting this error whenever I build in Xcode 6 GM Seed. It seems to be making my app insanely slow. What exactly does this mean and how do I fix it?
I had the following error:
Warning: Error creating LLDB target at path '.....'- using an empty
LLDB target which can cause slow memory reads from remote devices.
PS: im not able to run my app, its stuck on the splash screen
There is a thread in the Apple Developer Forum, https://devforums.apple.com/message/1010068#1010068 that describes how to diagnose this issue. I had his issue for Xcode 6 GM Seed, specifically - Version 6.0.1 (6A317). This isn't necessarily a solution, but it may help some people get a better diagnosis
Useful steps are as follows -
1) Create or modify your ~/.lldbinit and add log enable -f /tmp/lldb-api.txt lldb api to it.
2) Rerun your debugger session (no need to restart Xcode or anything)
3) Inspect the file at /tmp/lldb-api.txt. Look for a line beginning with SBDebugger::CreateTarget(...). Mine looked something like this
SBDebugger(0x7f83671fd600)::CreateTarget
(filename="/Users/xxxxxxx/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app",
triple=x86_64, platform_name=(null), add_dependent_modules=1,
error=the specified architecture 'x86_64' is not compatible with
'i386-apple-ios' in
'/Users/xxxxxxx/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app/Dino')
=> SBTarget(0x0)
4) Inspect the target file from the above log output, in my case -
file
"/Users/xxxxxxx/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app/Dino"
/Users/apanagar/Library/Developer/Xcode/DerivedData/Dino-gjuxikhuyokkqufeqmesmgjcxylu/Build/Products/Debug-iphonesimulator/Dino.app/Dino:
Mach-O executable i386
5) So, In my case my problem was the architectures I was building for. The target architecture for your project should match the one on the SBDebugger::CreateTarget() line in the log output.
Xcode doc's point out the following. I had to go through my nested frameworks and change some outdated architecture targets -
NOTE ABOUT 64-BIT ARCHITECTURE
An app extension target must include the arm64 architecture in its
Architectures build settings or it will be rejected by the App Store.
Xcode includes this architecture with its “Standard architectures”
setting when you create a new app extension target.
If your containing app target links to an embedded framework, the app
must also include the arm64 architecture or it will be rejected by the
App Store.
For more information about 64-bit development, see 64-Bit Transition
Guide for Cocoa Touch or 64-Bit Transition Guide for Cocoa, depending
on your target platform.
https://developer.apple.com/library/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
I am not sure if this will help in your case. But I tried this solution and it worked pretty neatly for me.
Pull up the terminal and type - rm -rf ~/Library/Developer/Xcode/DerivedData
This is supposed to remove the huge stack of DerivedData folder and make the app execute faster.
Did you use Architectures=$(ARCHS_STANDARD_32_BIT) and run your app on a 64 bit device? (iPhone 5S or iPhone 5S simulator)
Apple seems to be stricter with apps which don't support 64bit. So if there is no specific reason, I think it's better to include arm64 in your build architecture
NOTE ABOUT 64-BIT ARCHITECTURE
An app extension target must include the arm64 architecture in its
Architectures build settings or it will be rejected by the App Store.
Xcode includes this architecture with its “Standard architectures”
setting when you create a new app extension target.
If your containing app target links to an embedded framework, the app
must also include the arm64 architecture or it will be rejected by the
App Store.
For more information about 64-bit development, see 64-Bit Transition
Guide for Cocoa Touch or 64-Bit Transition Guide for Cocoa, depending
on your target platform.
Source:
https://developer.apple.com/library/prerelease/ios/documentation/General/Conceptual/ExtensibilityPG/ExtensionCreation.html#//apple_ref/doc/uid/TP40014214-CH5-SW1
This warning is solved by changing Build Settings :
Select Project -> Build Settings
Change 'Architectures' to 'Standard architectures (armv7, arm64) - $(ARCHS_STANDARD)'
This will prompt an alert stating iOS 5.1.1 and above are supported. Click 'Change Deployment Target to 5.1.1'
Repeat steps for Target (if not changed automatically)
Also, this is preferred build setting since Apple is forcing developers to build apps on 64 but architecture. Apple document Link
I have a Xcode project, that includes a Static Library project, that uses another static library that does not support the iOS simulator architecture (Vuforia SDK: libQCAR.a).
Vuforia SDK documentation states:
Vuforia applications must be deployed to a device to run; they cannot be run in the iOS simulator.
This is my project structure:
MyApp.xcodeproj
Classes
MyStaticLibrary.xcodeproj
Classes that depends on libQCAR.a
Frameworks
libMyStaticLibrary.a
libQCAR.a
My problem is that MyApp.xcodeproj does not build for the iOS Simulator because libQCAR.a is not built for the i386 architecture.
Is there anyway to make MyApp.xcodeproj ignore the libQCAR.a library when building for i386? I would be able to disable all the code that depends on the library with #if !(TARGET_IPHONE_SIMULATOR)
You can use a conditional build settings to specify the library you want to link only on a given platform, instead of adding the library to your project in the usual ways. Specifically, you will need to specify:
-lQCAR
in "Other Linker Flags".
Have a look at the attached image that should make things more clear (in the picture I am linking only for the simulator, you will want to select a device, I guess).
Also, do not forget to add the path to the directory containing the library to "Library Search Path" build setting (this does not need to be conditional; it would not do any harm on the simulator).
This issue seems very similar to: Xcode: Conditional Build Settings based on architecture (Device (ARM) vs Simulator (i386))
I believe sergio's solution is very close, but have you tried specifying the full path to the library under Other Linker Flags (potentially without "-l" - just the path)?
In my case, it should specify clearly which SDK uses which flags.
So in Any iOS Simulator SDK, you should not include the library.
In Any iOS SDK, you should include it. In my case, it's -lCloudReco.