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.
Related
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 got a few static libraries I want to use in my iphone app. When I try to run the simulator I get linking errrors.
I am new to iOS development, and I ran into this problem when linking against libraries I built previously;
file was built for archive which is not the architecture being linked (i386)
Which means all the functions I reference from those libraries gives me this:
undefined symbols for architectyre i386
I am not sure what to configure to make this right. The static libraries are build for armv7, supporteed platforms armv6 armv7.
I sorted a very similar error with a static library I was building for iPad. I believe my solution was to add "i386" to the Architectures setting for the project (Click on the Project -> Build Settings -> Architectures --or was it Valid Architectures?-- and click the '+' icon, type "i386" in the highlighted line). Anywho that should get you close.
Oh, one more caveat, I've read that we should set "Build Active Architecture Only" to "No" as well. It was already set for me, but that's something you might want to check.
After struggling with this same problem and following all the accepted answers of updating build settings, clearing the linker search path, etc.. I finally discovered an answer that worked for me.
Before building, make sure you select right type (iPhone Simulator) instead of iOS Device. Then rebuild. Otherwise, you're trying to use a library built for an iOS device (arm processor) on a simulator (i386). Should've been obvious, but wasn't.
Before:
After:
Now, look in the Products group in the Navigator > right click your static library (.a file) > Show in Finder, you'll notice that its in a Debug-iphonesimulator folder instead of Debug-iphoneos. I didn't pay any attention to the folder name originally, or I might have thought of this sooner.
Hope this helps.
I'm fairly new to the iOS SDK and Xcode and I stumbled across this XML-RPC framework https://github.com/eczarny/xmlrpc that I'd really like to use in one of my projects. I downloaded the sources, the initial target was set to Mac OS, so I changed that to iOS 4.3 but got the following dependency error:
target specifies product type 'com.apple.product-type.framework', but there's no such product type for the 'iphoneos' platform
So I removed all the targets and added a new one from scratch using the Cocoa Touch Static Library, and it seems like it's been built just fine. Now my question is whether this is the correct way to build that library for iOS development, and where do I take it from here? I can't find the .framework directory anywhere (the install dir was set to "#executable_path/../Frameworks") so I can't embed it in my iOS project. How exactly does this go? Thanks!
Thanks for your help and sorry if this is too "newbish". Cheers!
If you're using Xcode 4.x open the Organizer, select the Projects tab and then down the left hand side you should see an entry relating to the XML-RPC project. Select that and under the Derived Data heading you'll see a path which if you follow using finder should lead you to the folder containing the static library you've built.
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.
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.