I've been stuck with this problem for many days now.
I'm using google's objective-C SDK for getting user's name and email to login into my app.
I added the project and the classes to my project (because it didn't compile) and when testing everything goes right.
The problem is, when I compile for release and download the app directly into my iPad (iOS 5.1, it's working ok on ipads with iOS 6.0.1), the app is crashing when create google's login view controller.
the log sais:
Dyld Error Message: Symbol not found: _objc_setProperty_atomic_copy
Referenced from:
/var/mobile/Applications/58E1CEC8-FDAD-46B7-8684-92F919BA03A7/Nearpod.app/Nearpod
Expected in: /usr/lib/libobjc.A.dylib Dyld Version: 199.6
I've been looking for this error and everything I found are things like these questions: ARC App Crashes when accessing #property form ARC static lib and Xcode 4.5 error on IOS 5.
I've already checked that the Base SDK and IOS Development Target of both projects matches (Actually, this was what make the app work fine on Debug mode at first)
I have iOS Develpoment Target sett on 5.0 and Base SDK on Latest IOS (iOS 6.1)
I'd checked the differences between Debug and Release configs on both Projects and Target's and didn't found anything suspicious...
I've also added the -fobjc-arc flag to all gtl classes, and both projects.
can anybody help me?
After spending two days on this and making major changes to my code, I discovered that the solution is unbelievably simple: Just make sure that the deployment version of the GTL project (or GData project) is the same as deployment target of your main .
Related
I'm trying to build an ad-hoc build with test flight.
I have the OS Device selected and am trying to create an archive.
However I get the following warning.
(null): iPhone/iPod Touch: application executable contains unsupported
architecture(s): armv7s (-19031)
I have the following settings for my test flight target.
I can build fine for release.
It looks like you're using an old version of the TestFlight library.
The iPhone 5 uses a new processor (A6), with a modified instruction set (AMRv7s).
Since you are building your app with that architecture too, all linked libraries also needs to support it.
TestFlight provides a new version (1.1) of its library, with support for that specific architecture.
So simply download the new version of the library, link against that, and you'll be fine.
Your "Release" target is compiling and linking fine, because no symbol from the TestFlight library is actually used. But if you need TestFlight support for the iPhone 5, just update to the latest version of the library.
This warning is perfectly normal when you use an armv7 device to archive your application.
Think about it, you make an archive that includes the armv7s architecture (which is what we want) and the warning tells you that your armv7 device does not support that architecture (which totally makes sense).
To prove that even further, just hook up an iPhone 5 and try archiving and you will see that the warning will go away.
As far as I can tell Xcode 4.5 will not currently allow you to create Archive builds that include armv7s.
My project uses two 3rd party libraries (Dropbox and Flurry) and I reverified I had the latest iOS 6 builds included. I verified that all my other frameworks (and libsqlite3.0.dylib) were all located in the iOS 6.0 area. None of this helped.
I then created a brand new empty project from scratch and attempted an Archive build and received the exact same error. So after wasting 6 hours trying to fix this, I am tentatively concluding it is not possible to get rid of the warning.
Based on comments else where, apparently, it is not necessary to build for armv7s to run on an iPhone 5.
Any information to the contrary of anything I have posted here would be appreciated.
All you need to do is remove armv7s from the valid architectures.
Same question has been asked several ties I think.
I was displayed the same warning message when I archived in preparation for Ad-Hoc testing.
(null): iPhone/iPod Touch: application executable contains unsupported
architecture(s): armv7s (-19031)
I have removed armv7s as recommended above and the warning went away. What repercussion are there in doing this? What is armv7s supporting?
With semingly no changes to any settings or code from yesterday, what may have caused this warning to pop up?
I have tried dozens of configuration settings trying to get this to work, but still to no avail...
When I am trying to submit to the app store, the application loader is reporting the following error
iPhone/iPod Touch: application executable is missing a required
architecture. At least one of the following architecture(s) must be
present: armv7.
My understanding is that fpc 2.4 can only generate armv6 code anyway.
I have tried setting all build settings to only reference armv6, installed the previous version of XCode 3.2.6 and linked with the iOS SDK 4.3, hoping that this will address any references to armv7, but still no joy.
According to the XE2 Update 4 release notes, fpc 2.6 supports armv7, but despite the release notes having been available for weeks, there is no sign of the update!
Has anyone successfully uploaded an app using current tools (it surely has to be possible), and if so, could you please share your secret!
Thank you
I have upgraded to FPC 2.6 and all is okay.
I was reluctant to do this as it would make my development environment 'non-standard', however it was quite painless.
There is a paragraph in the release notes to the effect that nothing has changed in the xcode environment. This is probably accurate to an extent, but it is at least a little misleading as the compiler now builds armv7 code okay which is the issue I needed resolved.
I'm getting the following error when including static libraries:
missing required architecture i386 in
file
This worked 30 seconds previously, and only failed when I upgraded to Xcode 3.2.3. I've used "file" command to check - and, yes, XCode is building completely the wrong architecture (armv6 + armv7 instead of i386).
This seems to be a major bug in latest Xcode, where Apple has re-written the build / compile / link settings. There's a note in the release notes saying very vaguely that they've "Changed it" because it used to be "confusing". This is not helpful.
The build settings for the library VERY clearly say:
"Valid architectures: i386"
There's no confusion here - Xcode is building something other than what the target says it should.
The question is: how do you un-break this? How do you force Xcode to do what it's supposed to? I've re-installed Xcode from scratch, cleaned everything, and manually inspected the build files. There's nothing wrong (and, of course, it worked perfectly in xcode 3.2.2)
After considerable research, I believe the answer is:
"this is now impossible - Apple has deliberately hard-coded XCode to ignore build settings"
However, I've come up with a script that automatically builds ALL platforms of a project (which you HAVE to do with static libraries - you don't have much choice now, because Apple has disabled Targets), and the script could easily be modified to do all targets, instead of all platforms:
Build fat static library (device + simulator) using Xcode and SDK 4+
Right click on your Target app under Targets and make sure that the Base SDK is set to iOS.
I've created a iPhone static library project with two targets like this
Project
--> Library (Device) target
--> Library (simulator) target
The device target has the SDK set to the device so it produces an armv6/7 library and the simulator target is set to the simulator SDK so it produces an i386 library.
The issue I'm having is that the SDK settings on the targets keep getting overridden by the XCode active target setting. i.e. if I build the device target, but the XCode window is showing the active SDK as being the simlulator, XCode will build a simulator library instead of a device library, ignoring the settings of the target. Although it will put it into the *-iphoneos/ directory in the build directories!
I originally had the same issue with another static library project, and after a lot of playing around got everything to work correctly. i.e. The targets ignore the XCode active SDK because they have their own specifications of what to build.
The problem is that I don't know what made it work in that project and I have not been able to reproduce the issue in it either.
Does anyone have any ideas as to what is going on?
ciao
Derek
OK, I think I've figured it out.
Set the project SDK to the general setting, ie. Simulator SDK so that you get the APIs and libraries correct during coding.
Set each target to the SKD it needs to build. ie. device SDK or simulator SDK.
Leave XCodes SDK set to current SDK, effectively telling it to not override the targets.
I have been developing an iPhone app. and had the Base SDK set to "iPhone Device 3.0" and Deployment target set to "iPhone OS 3.0". Everything worked fine. I recently realised I actually needed to compile the project to run on devices using version 2.2.1 of the SDK, so I set the deployment target to "iPhone OS 2.2.1". Now when I hit compile I get 2079 errors all eventually pointing back to my header files saying "#endif without #if". My header files are surrounded by #ifndef/#endif clauses and I have checked every single one of them and all of these match up (since it compiles targeting 3.0 I'm assuming this isn't the problem anyway). I am using XCode 3.1.3. I have no idea what is going on and would appreciate any help with this. Thanks.
First thing to check is that you aren't using libraries that are only available in the 3.0 SDK. If you are using the MPMediaPlayer Framework, for example, you will probably get some compile warnings since those libraries don't exist prior to the 3.0 SDK.
My general advice for compile errors is to start with the first error and work your way one at a time. Generally, a single failure at the top will cascade and cause many more compile errors than actually exist in your code.
I found the answer, I had the target SDK set to the wrong version (2.2.1), when it should have been set to 3.0.