Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This is probably a totally noob question but I have missing links in my mind when thinking about linking libraries in iOS. I usually just add a new library that's been cross compiled and set the build and linker paths without really know what I'm doing. I'm hoping someone can help me fill in some gaps.

Let's take the OpenCV library for instance. I have this totally working btw because of a really well written tutorial( http://niw.at/articles/2009/03/14/using-opencv-on-iphone/en ), but I'm just wanting to know what is exactly going on.

What I'm thinking is happening is that when I build OpenCV for iOS is that your creating object code that gets placed in the .a files. This object code is just the implementation files( .m ) compiled. One reason you would want to do this is to make it hard to see the source code and so that you don't have to compile that source code every time.

The .h files won't be put in the library ( .a ). You include the .h in your source files and these header files communicate with the object code library ( .a ) in some way.

You also have to include the header files for your library in the Build Path and the Library itself in the Linker Path.

So, is the way I view linking libraries correct? If , not can someone correct me on this ?

share|improve this question
Check this out: cs.indiana.edu/classes/c304/ObjCompile.html The mechanics aren't much different than with C and C++. –  Berin Loritsch Mar 17 '11 at 15:33
add comment

2 Answers

Your ideas are generally correct, however it seems to me that you're in some sort of delusion about the amount of 'magic' that happens during a build:

these header files communicate with the object code library ( .a ) in some way.

The truth is simpler than this: there's no connection between headers and the library archive (.a files are compressed .o files). The only thing that the header file contains is the declarations of the functions used. This tells the compiler that these functions exist, somewhere. At the compilation phase, the compiler assumes that they do, and creates object code only for functions that are defined. Then, at the linking phase, the linker searches for the declared functions, that are not found in the original file. This is why you must #import/#include the proper header and import the dylib or add the .a file.

In fact, you could manage without the header file if you know the declarations of the functions you are going to use and declare them on top of the file where you are using them. Of course, this would be insane, since you are stripping a lot of information from the compiler and if you make an error in the function declaration, it would either produce a compile error for not using the function properly, or a linking error for not finding the (improperly declared) function implementation.

EDIT: I just tested the following code:


in Objective-C this generates the classic compiler warning for "implicit declaration of..." and the linker error "Symbol(s) not found".

The following code, however, fails with a compiler error "Funkster undeclared".

Funkster* hipster = [[Funkster alloc] init];

Therefore, while you can entirely omit declarations of C functions, declaring Objective-C classes is mandatory at compile-time.

share|improve this answer
add comment

The way you see the linking process is correct.

Producing a library eases : - source code protection - distribution - compile time

The process you describe is exactly the same for C, C++

You mention only static libraries but the process is similar for dynamic libraries.

share|improve this answer
But there aren't any third-party dynamic libraries on iOS. –  user4051 Jan 4 '12 at 10:36
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.