I was building my project perfectly but after updating iOS to 7.1, I was then forced to update Xcode 5.1 and now I'm getting error and warning messages:
4S 7.04 – builds – no error or warning messages
5S 7.1 – doesn’t build – mixture of error and warning messages:
26 x Value conversion issue
Implicit conversion loses integer precision:
12 x Linker build errors
Then I do the steps outlined in this blog post to remove linker errors – delete all conditional architecture and make sure arm64 is in the all the projects and targets: http://shazronatadobe.wordpress.com/2014/03/12/xcode-5-1-and-cordova-ios/
4S 7.04 – builds – warning messages:
12 x Format String Issue
Values of type ‘NSInteger’ should not be used as format arguments; add an explicit cast to ‘long’ instead
5S 7.1 – doesn’t build – warning messages:
26 x Value conversion issue
Implicit conversion loses integer precision:
12 x Format String Issue
Values of type ‘NSInteger’ should not be used as format arguments; add an explicit cast to ‘long’ instead
I think the warning messages are now affecting the badges as they are not reseting correctly
Are the warning messages relevant? And would they likely be affecting resetting the badges?
Okay, so I have gone back and forth with this for a while and I've got a few possible solutions for you.
Make sure in Xcode you are selecting both your project and the target within that project also and make sure your settings are setup like the forum post you mentioned.
Make sure you also change the settings on the CordovaLib project as well. Both the project and the target need to be changed, but it's slightly different. you also need to add i386 as a supported platform in the cordova project, but is not needed in yours.
Other things to check are.... Make sure you are using the right kind of provisioning profile... ie. Distribution for production phone builds and Development for team builds and testing on your device.
Check and make sure you are not missing a library you needed to import. You can usually tell if you are missing a library by the mach-o linker errors though.
Example: I removed a plugin from my phonegap project via command line. Well then I added it back and my project would not build using the 'phonegap build ios' command. I had to open the XCode version of my project within xcode then re-import the AudioToolbox library under the Linked files and then I was able to build again via command line.
Good luck, comment here if you need more help.
Please check my attached images might be it will helpful for you.
Related
I'm trying CocoaPods for the first time, because I've inherited a project that relies on it for several libraries. Articles like this one make it sound like it should all Just Work, even in the simulator.
But it's not working for me — I get an "Undefined symbols for architecture i386" for every class defined in a pod library. Moreover,there are a bunch of ld warnings along the lines of "ld: warning: ignoring file blah/blah/Build/Products/Debug-iphonesimulator/SocketRocket/libSocketRocket.a, file was built for archive which is not the architecture being linked (i386)". I get one of these for each CocoaPods library.
How do I get Xcode to build the pod libraries for the simulator (or link the correct ones, if they're being built)?
OK, I've managed to make it work, though I don't know if it requires both of these steps:
Deleted the derived data, as suggested here
In the Pods project, changed "Build Active Architectures Only" to "No" for Debug as well (it was already set to No for Ad Hoc and Release), as suggested by some of the comments here.
I know that step 1 alone didn't do it... but I don't know whether step 2 by itself would have sufficed. Certainly both of them together did the trick for me.
Adding this answer in case it's helpful to anyone.
To my surprise, it was the simulator version that I was using; iPhone 5 wasn't supported. Xcode gave me no sign of this until I switched to an iPhone 6 simulator, which worked. When switching back to iPhone 5, Xcode then complained that "MyApp does not have an architecture that iPhone 5 can execute."
This is all true and I knew that, but I didn't think of it as the previous error Xcode was giving me was that -lPods-MyApp was missing.
I was curious what would happen if I linked to an iOS simulator framework in a Mac app. So I copied UIKit to it's own folder (so the Framework search path wouldn't include all the iOS simulator framework, as like CoreFoundation is both on Mac and iOS but has different headers), and dragged it into the link section in Xcode. The error Xcode gave me was:
building for MacOSX, but linking against dylib built for iOS Simulator
file '/Users/jonathan/Desktop/macuikit/UIKit.framework/UIKit' for
architecture x86_64
Both architectures are x86_64, so how can it tell the framework is specifically for the iOS simulator, I removed all references to iOS in things like Info.plist, even tried deleted everything but the UIKit binary, but the same error came up. Is there something in the binary it self that tells the linker which platform it can run on, rather than just the architecture? I looked at the Mach-O header but there is only fields for CPU type and subtype, and neither has a value for the simulator as expected.
After a little bit of digging, it turns out that the platform on which the library can run on is indeed specified in the binary. In fact, you can edit the binary in your favorite Hex editor and make the linker skip this check entirely.
This information is not specified in the Mach-O header (as you have already realized). Instead, it is specified as a load command type. You can see the available types by digging through the LLVM sources. Specifically, the enum values LC_VERSION_MIN_MACOSX and LC_VERSION_MIN_IPHONEOS look interesting.
Now, find the offset for this in our binary. Open the same in MachOView (or any other editor/viewer or your choice) and note the offset:
Once the offset is noted, jump to the same in a Hex editor and update it. I modified LC_VERSION_MIN_IPHONEOS (25) to LC_VERSION_MIN_MACOSX (24)
Save the updates and try linking again. The error should go away. Of course, you will hit other issues when you try to actually run your example. Have fun with LLDB then :)
I got this warning when I added share extension to my project and archiving it
warning: skipping copy phase strip, binary is code signed: /Users/xxxx/xxx/xxxx/Build/xxxx/Build/Intermediates/ArchiveIntermediates/xxxx/IntermediateBui ldFilesPath/UninstalledProducts/XXX.appex/XXXX
The old question does not provide and insight to correct this . So I decided to ask again.
Warning during archive App with iOS 8 Extension in Xcode 6
Can someone please explain why this is happening ? Is it because the extension target is already code signed? If so, how to solve it ?
I knew that setting "Strip debug symbols during copy" to "NO" can clear this warning . But it is not actually solve the problem. And what is the drawback of not "stripping debug symbol"? Because my archive size is still the same whether I set this to YES or NO
Do not disable Strip Debug Symbols During Copy in your application project. This will bloat your app (if you have other unsigned dependencies).
It occurs because building the application project attempts to strip the framework but it can't since the framework is already codesigned. However the framework has already been stripped during it's build, so the warning is harmless. Xcode isn't doesn't seem to detect that the codesigned framework has already been stripped.
You should leave it as is.
"Compiled code usually contains debug information. This debug stuff is
helpful for inspecting running code in debugger, but less so for the
optimized code you would ship in distribution builds. Therefore it
gets stripped out when doing an Archive build.
The problem here is that PBXCp is unable to strip out debug symbols
from signed binaries because this would invalidate the digital
signature. So if you have a project that was created before Xcode 6.3
you will now get a warning like this.
To fix the warning simply change both values to NO. Removing them does
not work because the default value is still YES for both. The project
templates that came with Xcode 6.3 have these turned off by default.
Only projects that were started with older templates still have YES on
the Release line."
Source: https://www.cocoanetics.com/2015/04/skipping-copy-phase-strip/
I experienced the same warning and solved it by setting "Strip Debug Symbols During Copy" to "NO" in Build Settings of the containing app(not the extension), as you knew.
On the other hand, changing the same setting of the extension had no effect. This make clear the actual meaning of the warning. That is, stripping symbol does not mean the symbols "of the target" will be striped, but does mean the target will try to strip symbols "of embedded binaries".
Consequently, I believe the actual meaning of the warning would be that Xcode can't strip out debug symbols of the extension binary while archiving the container app, because the extension binary which need to be embedded in the container app "was" already compiled and frozen by code-signing before Xcode tries to strip out symbols of the extension binary while archiving the container app.
It seems like Xcode's default build settings related to striping debug symbols of the embedded extension binaries needs to be correctly updated not to show this warning.
In my case was related with 2 AppIcons (I forgot the fill them) , check if you have all the AppIcons in the xxx.xcassets file with the right xxpt.
From here I beg Apple to improve this check or enable an auto-tool to complete all the AppIcons set. It is crazy.
If you are using Xcode 9.34.1, click in the project settings. Use the filter to find the correct setting: type "strip debug". You will find the settings COPY_PHASE_STRIP. Probably is set to "Yes". Set to "No" to remove the warning.
I'm getting a lot of unused variable errors after updating to the new version of and Xcode 5.1.
Compiler is saying unused variables are errors, and checked the compiler settings that i didn't modify treating warning as errors.
This only happened after I updated to Xcode 5.1
There seems to be indeed an issue with Facebook iOS SDK and compiling on Xcode 5.1 even if compiling it by itself.
I opened a bug in the Facebook support system:
https://developers.facebook.com/x/bugs/1449419898627543/
As a temporary workaround - you can fix it by turning off treating warnings as errors ( a very good practice by itself btw I use for our SDK) by:
1. Open the Facebook proj file (or the project inside an existing project
2. Go to build settings of the entire project
3. Change the "Treat Warnings as Errors" field from YES to NO.
This will let you compile it even with these warnings - but do be alert for an updated sdk in the coming days.
The problem was that we were unintentionally compiling for 64bit in the internal compiler settings somewhere inside our scripts. Please be aware.
While I've followed the release instructions for 1.6 b1146 to the letter, I'm still unable to get Orbotix' "HelloWorld" to compile. I'm getting a lot of "Apple Mach-O Linker Error" messages. What am I doing wrong?
UPDATE: Hmmm. Looks like Build | Mach-O Type should be set to "Static Library". All but one of my error messages went away.
Those macho types get me every time. ;-0
UPDATE 11/18/13:
OK, when using Mach-O type "Static Library" setting, there is one remaining error message:
Command /Applications/Xcode 5.0.2.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool failed with exit code 1
How can I fix this?
UPDATE LATER 11/18/13:
I see in the release notes for 1.6b1146 a couple of sentences that read: "The QuickStart App Template has been removed from this release since XCode 5 is not compatible. Please use the following information to manually set up your project."
I've opened the Orbotix "HelloWorld" project and followed the instructions in the release notes, but I am still getting multiple Mach-0 errors. I am running it on my iPhone 5s, not the emulator.
Do the quoted sentences above mean that none of the Orbotix sample code in the /trunk/samples directory will work? Do I need to make my own HelloWorld project somehow by copying and pasting from the Orbotix sample code?
Phoebe719, I received word of your problems with the SDK through our customer service department. I'm sorry it took us a while for us to get back to you.
As for your issue, do you happen to be attempting to compile this onto an emulator? I myself have been baffled about the Mach-O linker errors when Xcode decides to not build to a device.
If you are building to an emulator, then I'm sorry, but there is no symbols in the iOS SDK for a mac to connect to a Sphero, and therefore, it just won't work. There is a mac SDK out there, but it is in a beta phase.
If not, then go ahead and leave a comment, and I'll see if we can't further diagnose the issue.
Phoebe - I just validated that the Sphero iOS SDK v1.6 Hello World sample compiles and executes on a 5s, 5, and 4s with no changes after downloading the Zip from https://github.com/orbotix/Sphero-iOS-SDK
Please validate that you are using a clean copy of the Hello World sample.