5

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!

Community
  • 1
  • 1
Karoly S
  • 3,180
  • 4
  • 35
  • 55

2 Answers2

7

To build the static library:

  1. Create a static library project in Xcode
  2. Add all the .c and .h file to the project
  3. 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:

  1. Choose File > Add Files to ""...
  2. Add the .xcodeproj for your static library
  3. Click on your app's .xcodeproj in the Project Navigator to show build options
  4. Click on your app's target and choose the "Build Phases" tab.
  5. Expand the "Link With Binaries Section"
  6. Click the '+' button
  7. Expand the "Workspace" section (you should see your library, a .a file, there)
  8. 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.

idz
  • 12,825
  • 1
  • 29
  • 40
  • 1
    Awesome thanks for the detailed answer! I'm running into a huge amount of errors so maybe I missed something else, I created an iOS Cocoa Touch Static Library, and added the files, fixing header reference errors as they came up, do I need to change the compile language to C anywhere? I'm thinking it doesn't just know, does it? – Karoly S Jul 25 '12 at 21:17
  • 1
    Xcode (or clang) chooses by default the language according to the file extension. E.g. .c for C, .cc for C++, .m for ObjC, and .mm for ObjC++. – Arne Jul 25 '12 at 21:21
  • @KarolyS As Arne (+1) says you do not need to do anything special as long as your filenames end in .c, but that does not mean that you do not have some work ahead of you... It all depends on what platform the original code was written for. If it was some UNIX flavor it should not to be too bad, if it was Windows it may be more of a challenge. One thing to look for are `#define`s that the code may be expecting to determine the platform (e.g. POSIX). – idz Jul 25 '12 at 22:54
  • Alright I've gotten to the point where I realize that when I thought I was fixing my header errors I was in fact making it worse. The error im getting is that certain header files result in a "Lexical or Preprocessor Issue, file not found" I've maintained the structure the library was given to me in, so I'm a a loss for what to do. Do yo have any ideas on what it could be? – Karoly S Jul 26 '12 at 20:38
  • You need to locate that header and either add it to your project or set the "Header Search Paths" to include the directory that contains that header. – idz Jul 26 '12 at 20:42
  • Wouldn't adding the whole library project to your app project really create a lot of bloat and stuff though? It seems to me like it's almost defeating the purpose of building a library - importing all the .m (or .c) and .h files themselves directly into the app seems like it would be simpler and wouldn't really have any additional drawbacks compared to this, would it? – GeneralMike Oct 02 '12 at 17:35
  • 1
    @GeneralMike when you link with a static library only the referenced object files are pulled in (unless you intentionally override this behavior). So, no, there should be no bloat. Adding all the .m or .c files can be time consuming and they will be recompiled subject to the settings of the project they are added to. Static libraries give you a snapshot of the compiled code, with a specific set of compilation options. Another real benefit is the fact the Xcode, although it is getting better, seems quite slow to compile; when you are in the modify-test-fix-recompile cycle this is a big benefit. – idz Oct 02 '12 at 21:20
  • Ahh, I see. I guess I just don't understand much about how Xcode builds projects, and how the whole "2 projects in 1 workspace" thing works. I just assumed anything that gets imported into the project gets built with it, so importing the library project into the app project would be the same as importing all the files in the library project. I guess this is not the case - importing the library project is just to make it easier to locate the .a file, correct? – GeneralMike Oct 03 '12 at 12:45
  • @GeneralMike Importing the library project also means that Xcode can correctly locate the correct .a file. Unless the library project combines architecture-specific .a files to create a "fat" library (one which contains multiple architectures) there will .a for each architecture. Xcode understands this and will pick up the correct one. – idz Oct 03 '12 at 17:06
  • Sorry to bother you again idz, but to import the .xcodeproj for the library, the source code for the library would have to be available to the app developer, correct? Is there a way around this? I'm developing an app, and I've been working with a third party that is trying to provide the library for us, but they obviously cant give me their source code. – GeneralMike Mar 07 '13 at 15:54
  • @GeneralMike In that case (where you are working with a precompiled static library) you just add the library (the is, the .a file) and the headers to you project. Adding the headers just helps Xcode find them. If you prefer not to add the headers you can set you 'Header Search Path' to include the directory where the headers reside. Hope this helps. – idz Mar 08 '13 at 20:09
  • So in the steps 1-8 you have above, I just replace #2 with "Add the .a and all .h files for your static library" then continue with #3-#8 as without doing anything differently? Do I have to do anything special to associate the .h files with library? I tried doing this with a test library I made from the Cocoa Touch Static Library template in Xcode, but when I try to run the app I added the library to, I get a warning "ignoring file ... myLib.a, missing required architecture i386 in file ...", and "undefined symbol" errors for all the methods in my library. – GeneralMike Mar 08 '13 at 21:12
  • @GeneralMike The library must contain all the architectures you will be compiling for. Typically now that is i386, armv7 and armv7s. In the case of the test library you mentioned above this is what went wrong. If the precompiled library you are trying to use does not have all the architectures you need you will have to contact the vendors and request a new one. – idz Mar 08 '13 at 22:57
0

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.

Arne
  • 2,624
  • 3
  • 24
  • 45