I'm fairly new to ios programming. I've got an app that I think is almost ready for the appstore. However, I have one remaining warning and I'm not sure how to track down where the problem lies.
Here's the warning:
(null): Ignoring file /Users/maclehose/Library/Developer/Xcode/DerivedData/epidemiologyCalculator-esumevitgvkrmsfrmqeerqjyjfoh/Build/Products/Debug-iphoneos/epidemiologyCalculator.app/epidemiologyCalculator, missing required architecture arm64 in file /Users/maclehose/Library/Developer/Xcode/DerivedData/epidemiologyCalculator-esumevitgvkrmsfrmqeerqjyjfoh/Build/Products/Debug-iphoneos/epidemiologyCalculator.app/epidemiologyCalculator (2 slices)
Can anyone give me any specific advice on how to track down the source of the warning?
Thanks,
Rich
Go to targets and then Build Settings. Then turn the architectures to (armv7, armv7s). Like this you can silence the warning.
But then when you change it like this, it means that your app doesn't gets compiled for the 64-Bit architecture (iPhone 5S uses it).
You don't need 64-bit setting, if performance is not an issue. However if you really need it, you'll need to compile and build CorePlot library from source by adding it as a dependent project inside your app.
Related
I'm creating a binding for a library that I do not have access to the source for. It was built only for ARMv7.
First issue:
It will not work in the simulator - this is obvious, but the problem is that if I compile and run to the simulator Xamarin will break at that code and stop the simulator. Plus it crashes. Did I do something wrong with the binding or is this the way it is and I have to put in a conditional to ignore the commands? We're trying to turn the library into a binding for general use. So it would be nice if somehow I could put this condition in the binding DLL.
Second issue:
I'm concerned this library will not work on 64-bit architecture via Xamarin since it is only compiled with ARMv7. Can anyone confirm or refute this? The library works with 64-bit builds as we have used it before with other app engines.
Thanks so much for your time!
Someone correct me if I'm wrong but I think that Apple will no longer let you submit an app if it doesn't support 64 bit. I've always included 64bit binaries when submitting so I can't be certain.
how can I fix this error?:
http://i.stack.imgur.com/zmZea.jpg
I got this error when compiling a simple c++ file but I don't know why
When I compile this file with iOS 6.1 sdk it works but I want it to work in iOS sdk 8.1
My iPad:ipad 3 wifi
My iOS version:8.4
It shouldn't be problem with the architecture. As far as I know Apple hasn't changed Armv7. From what I see, its a linker error, probably caused by libraries not being linked in correctly. Pretty clear when it says: ignoring nonexistent library. This type of error could occur if you import a header and fail to link it against the correct library OR if you just straight up include a header for the wrong architecture -_-.
So thats the diagnosis. I guess the rest of the hacking is up to you since no one here has any clue what you have done to the poor iPad.
I apologise for a dumb question. I really had tough time with this.
I am now, converting my existing code to support 64-bit. My app uses few frameworks
(I use kstenerud/iOS-Universal-Framework)
And I get this error.
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_MyFrameworkClass", referenced from:
objc-class-ref in MyUI(iPhone_MyVC.o)
MyFrameworkClass is defined in my framework, Which I built using the below settings
In my project, I use this framework and have the same build setting as above.
I am sure, I have the same setting throughout. But still I get this error. Am unsure, what else Am I missing.
You can build the static library for individual architectures and then 'lipo' them together.
Check out the excellent article here: http://blog.diogot.com/blog/2013/09/18/static-libs-with-support-to-ios-5-and-arm64/
You are building your lib for arm only, then you try to run it on x86 (simulator).
Make a lib that supports x86 (64) and use that for debug, the one you have for production.
You should include more of the error message for better help, but it looks as though whatever is providing the MyFrameworkClass class doesn't have a simulator x86_64 slice.
With Xcode 6, you update your project to use Xcode's provided framework target instead of using kstenerud/iOS-Universal-Framework
I suddenly started getting this error after upgrading my Xcode 5.0.2 to Xcode 5.1
warning: ignoring debug info with an invalid version (0)
There are like 22 of these warnings coming up when compiling my code...
I haven't encountered anything like this before… Please can anyone help.. thanks in advance..
In XCode target BuildSettings, search DEAD_CODE_STRIPPING and set Value to NO.
This is a bug with LTO and -dead_strip. The workaround is to stop using one of them.
way Link Time Optimization (LTO) works is that the compiler stops half way through and emits the .o file as "bit code" (the internal clang IR) instead of compiling down to mach-o. This is drive by the -flto compiler option. When the linker encounters bit-code .o files, it loads up the back end of clang (libLTO.dylib) and merges/compiles all the bit-code files into mach-o then completes the link.
The Link
Check files that are related to warnings. If will be probably a third party library. Try to recompile that lib with new Xcode.
I have two 3rd party libraries. One just has a build for armv6 and the other just has a build for armv7. I need to use both of them in my iOS enterprise application. I've asked the armv6 library vendors to supply a armv7 version, but they haven't been able to do so. (Note: I've already got the answer and will provide it. Someone else asked this in a comment and there wasn't enough room to answer, so I've created its own question, and will provide my answer.)
The answer is to hack the armv6 library into thinking it's an armv7 library. This will get you running until the vendor supplies the library. The reason this works is because the arm spec requires all arm architectures to be able to run code generated by previous architectures. So if an armv6 library told the linker it's an armv7, the processor should still be able to run the code. Of course, you can't go the other way. Use otool -h on both libraries to see the cputype and cpusubtype. On my libraries it was 12 for both cputypes, and 6 and 9 for the subtypes, indicating armv6 and armv7.
Using a hex editor, look for the hex string 0xcefaedfe which is the marker MH_MAGIC (0xfeedface) reversed due to big/little endian.
Following that, there's a whole word with just 0xC. That's the 12 for the cputype. Next is a word for 0x6. Change that to 0x9 for all cases.
Now ld will think your library is an armv7, and act accordingly.
You're probably not done, because the armv6 may have linked in some thumbs library routines. If you get link errors (I got some for switch8 and switch16), you need to find the Darwin code that has them. Look for the file lib1funcs.asm on the web. This will probably have your missing functions. They're probably conditionaled out, so adjust the #ifdefs and make sure they're being compiled. This file tries to open some includes at the end, but since they're at the end, they don't affect anything, so just comment them out.
Yes, it is a tremendous hack, but it gets you up and running. If you get your revised library, you just have to drop it in. No code change required. If it works for you, you're still using Apple's code, and it would be the same code you'd be running if you were armv6 only.