When I get a 3rd party static library, I can use it in my debug or release builds for both the simulator and device. However, when I build locally, it is targeted for debug simulator/device or the same for release. I then have to coordinate my host app to match the library build. How can I create a single static library build that works with all build versions of the host app like many 3rd party static libraries do?
I don't think there's a "magical" solution for the iPhone for this.
I once looked for the same thing didn't find any "easy to use" solution.
Best I could find :
http://www.clintharris.net/2009/iphone-app-shared-libraries/
Especially the part regarding "Fat libraries", that refers to http://latenitesoft.blogspot.com/2008/10/iphone-programming-tips-building-unix.html
But the MAKE configuration doesn't look easy (at least for me).
The way I do it :
I build the static libs separately for all configurations I need (simulator x86 debug, and device arm debug for instance). This gives me two different .a files.
I renamed them mylibrary_arm.a and mylibrary_x86.a
Then, for any project that wants to use those 2 libraries, I drag and drop THE TWO .a FILES into the client project that needs the .a library + the .h headers that will enable the use of those libraries.
Then, when I choose simulator or device in this client project, the compiler chooses the right .a AUTOMATICALLY to compile and run properly .
So in the end, the only boring phasis is the generation of the .a themselves, but the use of them is quite easy and XCode adjusts itself automatically.
Related
I want to create static library through Xcode 4.I took one .a build using cocoa Touch static library.When I add .h file and .a file into new project ,it gives missing required architecture i386 in file error.I have to set any
Header search path in xcode 4 like earlier versions.?
1)what is the best approach, can i develop static library which will work in simulator and device as well through xcode 4?
2)some tutorials are saying that we have to develop
a)Create a build for the device (the armv6 and armv7 architecture).
b)Create a build for the simulator (the i386 architecture).
cant we develop single .a component for all architecture?
which one is the right in above?what is the right approach?any help please?
A nice way to solve this is to use the workspace feature and include the library’s target in the main project. That way the library gets compiled more or less automatically with the correct settings and it’s much easier to propagate changes in the library code. Of course, this is only an option unless you want to distribute the library without sources to other people.
I have a C++ Library that I'd like to link against my iPhone project. How do I do that?
Just drag it in and make sure that the header files are available. That's it :) Make sure that the .a file (assuming that your library is a .a file) is listed on the build phases tab under "link binary with libraries".
You have to be sure the library is built for iOS, specifically for the architecture you intend to deploy on. For instance, an Armv7 will not work on the simulator or on a pre-armv7 device like the 3G. If you want this approach to work flawlessly you probably should build a .a library for all architectures, (armv6/armv7 i386) then combine them into a fat library with the "lipo" command. This assumes you have access to the source, of course. There was a post here on SO regarding exactly how to build a fat library from source. After you've done this then it would be a simple matter of drag/dropping it into Xcode along with the headers.
I have an Xcode 4 project that has my iOS app and a static library (which is a separate project, but included in the app's project, still with me?).
Okay so anytime I make a change to the static library, in order to see the results when running the app, I have to do a clean and then run. Is there a way to have it automatically clean the static lib before building the app's target?
Is the static library's .a filename colored red in the project structure?
Step one: make a backup of your project if you don't have one already :)
Step two: try what worked for me:
Remove the static library red .a nodes from the project structure.
Removing these nodes will break the linkage between apps and libs that you've established in your project settings (under "Build Phases > Link Binary with Libraries"), but don't worry -- you can set them back up later.
Now go through all your static library projects one by one and build them individually, targeting "iOS Device" (as opposed to Simulator.) It is important to target iOS Device -- this is the magic step.
Once all your static libraries have been built for iOS Device, then go back through your project settings and re-establish the link between your Apps and your Libs (e.g. by going to "Build Phases > Link Binary with Libraries" in the App's project settings).
Because we built the static libs targeting iOS Device, the newly appearing .a nodes should appear in black in the project structure.
Changes to the static library source code should now be picked up by the Build (or Run) process for your main App, even if you didn't clean or modify the main App. If you're like me, and the bulk of your development is inside a static library, and you rarely make changes to the app project, this is a HUGE headache saver.
If you ever run a Clean while targeting "iOS Device", the static lib nodes may go red again. I'm not sure if this will break things again.
It may not actually be necessary to remove nodes / break the linkage to fix the build. It might be enough to just build each library targeting iOS Device. But, I'm not sure about this, so I just wrote up the whole procedure that worked for me.
I want to use the ffmpeg library (and maybe others) in my iPhone App.
But I have absolutly no idea how I can use the files that are in the downloaded zip, and get them to work in my XCode project.
I read something about .a files and frameworks. Maybe you can give me a description how to implement it?
1st, you're not allowed to do anything with open-source on apple market : basically, any open-source library tainting your code (thus GPL, but also LGPL as dynamic linking is forbidden) will have your application removed if spotted. The VLC case (removed from app store) proved that GPL is not compatible for app store license (look for app store and gpl and google and you'll find hundreds of links)
Second, you have to transform the code you received (say source code) into a static library (a .a file). To do that, you need to compile it, here you have basically 3 solutions:
put all the files into your xcode project and tweak until it works (thus not creating static library, directly merging the code with yours) : this seems the easiest, but will be a nightmare in terms of maintenance (each time you'll want to upgrade the statuc lib)
compile externally, by hacking the makefile to use the correct compiler (the one in for ios, in iphone platform folder)
add a subproject in your xcode project to compile the library
My advice goes for 2 (that's what I do with boost) but it's not a straight path
EDIT : don't forget that software video decoding will drain your battery and you might have poor performance
I have an Objective-C iPad app I want to build an opaque static library from so I can give it to testers using X-code to test without giving them the source code. How can I do this?
Use a "Static Library" target. Add your source to the target, and build. Since Objective-C is compiled to machine code, the resulting library is binary only. That said, Objective-C binaries are not as difficult to dig into as C++, for example. Since Objective-C uses runtime dispatching, many symbol names are retained. Using classdump at the command line, users will still be able to at least learn the classes and selectors in your binary. If this is unacceptable, you will have to consider writing the library in pure C (I discourage you from using C++ since it would require clients to use Objective-C++ just to use your library).
Objective-C is compiled, so just compile it and then distribute the binary.
If you want the recipients to be able to test on both a device and the simulator, build a fat library. I liked this article on fat binaries.
A static library is not very useful by itself. You will probably want to copy your entire project, remove all headers and sources except main.m and add your static library. That way all the resources, frameworks, and build rules will remain in tact. Then send along the library, project, and all resources.
Unless there is a specific reason why you would want testers to access your application through XCode, you can instead build a binary for ad-hoc distribution that can be installed on up to 100 devices. Check up "Ad Hoc Distribution" for the iPhone.