I have successfully developed a small iPhone+Monotouch (latest version) application with Monodevelop 2.8, which use a "compiled by me" version of SQLite to enable FTS4.
To compile SQLite as static library (libSQLite.a) I used this topic as tutorial: How to use FTS in SQLite with Monotouch for iOS
Also I've followed this tutorial to create a Simulator+Device compliant static library:
Build fat static library (device + simulator) using Xcode and SDK 4+
Things are working great on the simulator. :)
Bad news comes from the device, an iPhone 4 with iOS 4. When I deploy and run the application on the device, it suddenly crashes.
To use the libSQLite.a static library in my monotouch project I've followed this tutorial http://docs.xamarin.com/ios/advanced_topics/linking_native_libraries
It seems that something is going wrong when running the application on the device compiled with this additional command:
-gcc_flags "-L${ProjectDir} -lSQLite3 -force_load ${ProjectDir}/libSQLite3.a"
If I compile and deploy the application without the additional command (to use the static link library) the program start without crashing.
Any suggestion?
Anybody already use SQLite with FTS4 on a monotouch application for iOS?
This is related to our bug #707, in short it's an issue which is usually provoked by using external libraries with thumb instructions. This also means the workaround is easy: just disable thumb support in Xcode when compiling your static libraries.
As a sidenote we've tracked down the bug and it will hopefully be fixed in the next MonoTouch release.
Related
I made library named as 'libDigitalSignature.a' in Xcode 7/iOS 9 and compile it on iPhone 4s. I implemented this library file in a different app and it is working properly on iPhone 4s. But when I run the same app on iPhone 6+, it gives me the following error:
I got the same error in vice versa. Do I need to make this library on possible devises then merge all the '.a' file using following command:
lipo -create "libLogger_simulator.a" "libLogger_device.a" -output "libLogger.a"
I think you need to set Build Active Architecture Only to NO when you make your static library. Also, I would not recommend using a static library with Xcode 7. There are a lot of advantages to using a framework instead.
You have to recompile the static library with arm64 architecture.
Select your target and then you build settings
The iPhone 5s/6/6+/6s/6s+ all are 64 bit, so to run on these devices you need to recompile your libarary with latest settings as mentioned above
I have a static library (very simple, no includes) which builds fine with "-arch i386", I can use the demo method in this library and everything is fine. As usual I have an .a file to link in my project.
Unfortunately I want to use this library in an iOS project, so when I use the iPhone Simulator everything is fine with the library built with "-arch i386" (because this is the processor the simulator uses). If I now want to build the library with "-arch armv7" (or "-arch armv6") for my ARM-based iPhone device I get in Eclipse and in Xcode the same error message: (in Xcode:) llvm-gcc-4.2 failed with exit code 255. Same exit code in Eclipse (255). With "i386" everything works.
Must I install anything in addition to my Xcode 4.2.1 on OSX Lion to make compile the lib for my ARM-Device?
The issue lies in the fact that Xcode 4 builds static libraries for each build rather than one unified universal build. So my guess is that you are just adding the build for debug-simulator and not for debug-device. Your best bet, add a script to your static library to build them all into one.
This post here on SO saved my life. Hopefully it will help you too.
I recently ran into troubles building an app with latest iOS 4.1 SDK and running it on device with iOS 3.x. App works OK on 4.x devices and iPad, but crashes on devices running older 3.x iOS.
Problem appears to be in linker, since crashes are obviously caused by calls to 3rd party libraries used in the project. The linker (or even compiler) suspicion is supported by fact that when I build the app with older 3.1.3 SDK, it works as expected.
My Release configuration uses iOS 4.1 as Base SDK and iOS 3.0 as deployment target platform, compiled with LLVM GCC 4.2. I also tried GCC 4.2 compiler, but it didn't help too.
I've found that there's some bug in linker/compiler in this version of SDK, but none of proposed solutions worked for me.
I desperately need to resolve this issue, so any help is highly appreciated.
Thanks to everyone for any hint or advice.
Just to let you know that if you are using something like iAd framework, you need to add this framework as "weak dependency" in the Target Info Pop-Up :-)
If it's a librairie, could you list them ?
Good Luck !
I guess I am too late at answering this one. But still - If you have the 3.1.3 device with you, doing an in-system debugging by loading an app with a developer profile gives you what caused the crash. I faced a similar problem when my apps used to work fine on the 4.0+ devices but used to crash immediately upon startup when I tried it on 3.1.2 device. I compiled it with a developer profile and then did an in-system debugging. I found out that I was using a class UIPopoverController which was brought in with iOS 3.2 and hence used to fail for my 3.1.2. Putting in the necessary checks for this resolved my problem.
Hope that helps.
I just updated to iPhone SDK 4 and am trying to debug on my device with 3.1.3 installed. Before the update, I compiled with Base and Active SDK set to 3.1.3 and all was well. After the update, I'm limited to SDKs 4.0 and 3.2--setting the base to 4.0 and iPhone OS Deployment Target to iPhone OS 3.1.3, I'm able to build and install on my 3.1.3 device, but receive the following error:
Error from Debugger: mi_cmd_stack_list_frames: Not enough frames in stack
I'm not using anything specific to the newer SDK, as I haven't touched a bit of code, just updated the SDK/XCode. So what am I doing incorrectly? The application runs as expected on an iOS4-installed device. Are there changes to pre-existing API's that need to be weakly linked perhaps? Thanks for all help.
Have you tried removing the app completely from your dev device, doing a build -> clean all targets, and then build again to your device?
I found this answer on macforums. If it's correct, then you probably have a memory corruption problem in your app that is confusing the debugger. Perhaps over-releasing something somewhere.
This probably isn't related to the SDK you are compiling with. It's possible you had this problem in your app all along but it just didn't show up until things moved around with the new Xcode, SDK, etc.
EDIT - I just ran into this problem myself trying to update an older app of mine to 4.0. It would run fine in the simulator and would install and run on the device except it wouldn't run in the debugger on the device. Anyway, I finally decided it was the .xcodeproj file that was corrupt or bad in some way and created a new project, copied over my source files to the new project and now it all works again. It's a pain but it only took about 20 mins to duplicate all my settings and I spent a couple hours trying to get the debugger to work.
Myself (and probably many others) are concerned about "will I still be able to compile/install apps for v3.1.3 of the iPhone OS?"
And what version of xCode does it become IMPOSSIBLE to ever write v3.1.3 apps again?
(Without installing a second copy of an older version of xCode.)
I've read the mile-long document that Apple wrote on the subject... but it sure would be simpler to understand if they just LISTED the various versions of each... instead of writing long paragraphs.
If you have:
Mac OS version 10.x.x x
xCode version x.x.x
SDK version(s) x.x.x
you can produce apps for iPhone OS x.x.x through x.x.x?
I have searched for hours however I still have no clue what is wrong with my configuration.
My project uses a self-written libray (myLib). This library is compiled to work only for simulator and it works perfectly there.
What do have to change so it compiles for my iPhone Device as well?
This is my current warning:
ld: warning: in /.../myLib.a, file is not of required architecture
This is my configuration (of myLib.a)
I found a lot of articles explaining the reason for this error however I could not find a solution:
The simulator runs on an x86
architecture, while the device uses an
ARM architecture.
What do I have to change to get my library working on my iPhone?
Thanks
Edit:
What I did so far:
Cleaned both projects
Set library to 'Device' (3.1)
Built the library
Dragged the .a file of my library into my application
Result:
This works in simulator but setting the active sdk to device still raises a file is not of required architecture error.
I also tried mahboudz ( thanks for your support) link.
It explains howto built the project using a shell script.
However XCode keeps complaining that the library file is of the wrong architecture and the build fails.
This has to be a really stupid beginners mistake.
You need to add both .a files,the one built for the device (build/$config-iphoneos)and the one built for the sim (build/$config-iphonesimulator) to the new project. Make sure you name them differently before dropping them in. This is how admob and similar offering ship their static libs.
You need to compile your library for Intel so the Simulator can use it (which I gather you have done already), and then compile it for ARM, so it can run on the iPhone. Then you have to merge the two libraries. There are different ways to accomplish that, or make it more automatic.
Here are some links to help you:
http://blog.stormyprods.com/2008/11/using-static-libraries-with-iphone-sdk.html
http://www.clintharris.net/2009/iphone-app-shared-libraries/
I've met the same problem too. But seems you don't need to drag two .a files into the app project to solve this problem. This is what I did:
Drag the static library project into app project's framework group
"Get Info" for the target in app project
Set the direct dependency of static library
Make clean all unnecessary builds(for example the simulator build) in the static library project
Build in the app project