Is it possible to compile multiple objective C (.m) files into one .a library? The resulting code would be used in iPhone apps via XCode.
If yes, do you have any links to a tutorial, or can you paste a Makefile?
You do not need a tutorial. Just start a new project, select iOS / Framework & Library / Cocoa Touch Static Library and start adding a files. That is it. Compiled lib will have all the files in place. Provide headers to consumers for all included files so they will know what's inside. It is pretty simple, let me know if you need an additional clarification.
Related
I have created lib.dylib dynamic library. I want to use that library in my application.
What are the Build setting and build phase settings are required?
Steps to use the library in objective-c.
so there are 2 ways...
1) if the Dyld is available at link time, then you just link against it. (in Xcode you add it to the link build phase of the target you are building.)
if using a framework: The headers will end up in the header search path so you can #import <framework/header.h> them.
2) if it isn't then you will need to open the dynamic library with dlopen, then you read in each function directly... this is much more of a specialty task, like dealing with a plug-in architecture.
there are some tricky thinks if you are supplying the dynamic lib then there are issues with the library install path being relative to the executable... but you will just have to tackle them if you hit them (start by googling #rpath)
I have a library that I'd like to use in a Cocoa project, (specifically vgmstream).
To use this, is it as simple as dragging the necessary files into Xcode? Or would I have to build or bundle it in some way in order to use it?
If you have built static/shared libraries and the header files, you can easily drag them into the project. Otherwise, you'd have to build the libraries your self, or drag in all the source files to the project.
The so called framework that Xcode uses, is just a folder with .framework extension containing a Headers folder and a static library with it's name the same as the folder name without extension.
I've done a some looking around but most of the answers I've found have been or felt incomplete and have left me a little confused. I have been given a C Library that I need to compile into a static library using XCode 4.3 and then use in a separate iOS app project, but I'm unsure about how to proceed. I'm not sure if the directory structure matters or not, but here it is anyways:
Library -> Section1 -> src -> .c files
-> sec1 -> .h files
-> sec1.h
-> Section2 -> src -> .c files
-> sec2 -> .h files
-> sec2.h
I've been trying to work from this: http://blog.stormyprods.com/2008/11/using-static-libraries-with-iphone-sdk.html which was linked in a question similar to this one though being from 2008 its fairly out of date, nor could I get it to work. There is also this question: Including external C library with Xcode but it doesn't go into the details of actually generating the library, before then including in a separate project.
If someone could provide a clear and up-to-date answer I, and many others, would very much appreciate it I'm sure. Let me know if any more information is needed!
To build the static library:
Create a static library project in Xcode
Add all the .c and .h file to the project
Compile
The easiest way to use this library is then to add this static library project to you application project. This avoids having to worry about creating fat libraries (i.e. libraries with code for both the simulator and device).
To add the static library project to your application project:
Choose File > Add Files to ""...
Add the .xcodeproj for your static library
Click on your app's .xcodeproj in the Project Navigator to show build options
Click on your app's target and choose the "Build Phases" tab.
Expand the "Link With Binaries Section"
Click the '+' button
Expand the "Workspace" section (you should see your library, a .a file, there)
Click on your library and you should be good to go.
Apologies for excruciating level of detail above, but somehow people always seem to forget to do steps 4-8 and then they wonder why they are getting link errors!
Xcode will not be able to find the headers for your library. You can either add the public headers to your project as you would any other header file or set the "Header Search Paths" in your build settings.
Try the Universal Framework project, as seen on github: https://github.com/kstenerud/iOS-Universal-Framework/. I have used this extensively, and it works nicely. You just create a new XCode project for that library, put in all the source and header files, and it will build a static Framework. That you can use in other projects, and you also don't have to worry about the header search paths.
I'm working to create an iOS static library that I wish to sell. I've walked through the steps for the initial builds and have generated the .a/.h output.
When I include these files in a separate project, I don't see any way to browse the contents on the .a file.
HOWEVER, when a line of code in my library crashes the app (like I said, it's still in development), the debugger shows the entire class (.m) file to me. What's up with this?
I don't really understand what all goes into static libraries, and I'm not sure I compiled that version for both simulator and device. Could that have something to do with it? If so, could someone explain why?
Thanks!!!
Don't worry, your source code is not included in the archive (.a) file.
Xcode is smart enough to find the source code file on your computer, based on the debugging information embedded in the file. If you build the library using the "Release" configuration (or otherwise modify the build settings so that debugging symbols are stripped) and don't have the source anywhere on the machine, a developer will have to resort to their knowledge of x86 or ARM assembly to figure out how your code works.
By the way:
Since a lot of Objective-C is handled at runtime, a lot of class names and selector names will be visible in your library. That's just how it works. You could try to obfuscate it, but I think your time is better spent writing more useful code to sell.
If you want to give people a static library for iOS development, you'll want to build versions for the iOS Simulator (x86) and the iOS Device (arm) and then use lipo to combine them into a single fat static library. Search around for "lipo xcode fat static library" for different ways to do this. Some solutions are more convoluted than others.
I had the same issue. #benzado is right about what he has mentioned. But I had to strip debugging symbols to solve the issue. To do so, I had to change Build Settings of project library before build as mentioned below.
Select your Target and go to Build Settings. Set
' Strip Debug Symbols During Copy ' to YES
' Debug Information Format ' to 'DWARF with dSYM File'
' Generate Debug Symbols ' to 'NO'
' Symbols Hidden by Default ' to 'YES'
To see what are these for, refer Apple Build Setting Reference
And build the library using the "Release" configuration. This worked for me.
If you have a project for static library with all .m files on your computer then every copy of this library (.a file) will be symbolicated with its .m file while debugging in xCode.
xCode doesn't search for appropriate .m file through all your disk. It knows the place of original project. So if you distribute only library it fully hides your initial code.
To make sure you can copy your library in some new project then clear .m file in library project.
From this moment any attempt to debug methods of library will give empty file on screen.
I have a project with two targets, one is a Cocoa Static Library, the other is the accompanying test project. Despite building the main project in different ways over and over again, I cannot find the .a file that I expect it to produce.
In fact, I cannot find the build folder associated with the project. I need to link to the library in an app, but cannot do so if I can't find the file to link to.
These properties are correctly set:
(Build Products Path) SYMROOT = build
(Intermediate Build Files Path) OBJROOT = $(SYMROOT)
All tests pass (which means the code MUST be building right?)
Breaking the code causes the build to break - again suggesting that it is building.
Also, the "Products > libproject.a" file is red in the xcode project navigation
I also checked the DerivedData directory, but all the seems to get created is the objects fot the OCunit stuff. Still no .a file against which I can link.
Where is my .a file?
Any help would be much appreciated.
It's probably in ~/Library/Developer/Xcode/DerivedData/ somewhere.