/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS2.0.sdk/System/Library/Frameworks/CoreGraphics.framework

That worked for me.

When you use a symbol defined in a framework the linker resolves that symbol by including the code block associated with it and that may include references to symbols that are as yet undefined. That is what has happened in your case, you have used a method that references CGRectZero, the underscore is added during code generation so that it’s symbols never conflict with symbols created by people.

Frameworks are dynamically linked libraries so that the code isn’t actually included but it’s easier to understand if you ignore that fact. The fact that the code in the framework has an unresolved reference is noted by the linker which tries to resolve that symbol.

You can use the CLI command nm to examine the symbols included in a framework. The man page refers to sections and they aren’t that obvious, the text section is read only and contains mainly code but can contain constants, the data section is initialized global variables and the bss section is unititalized global variables.

nm /System/Library/Frameworks/AppKit.framework/AppKit
reveals that the framework AppKit has a unresolved reference to strncpy which is provided by libc. I doubt that you include the header where strncpy is defined although it’s hard to be sure but that doesn’t affect the linker, if you use code in AppKit that uses strncpy then the linker will resolve it by including it from libc.

CGRectZero is defined in CGGeometry.h and I didn’t specifically include that file. CGRectZero is listed as a global C variable in the documentation set as part of the core library, so does that explain why I don’t need to import the header in order for the compiler to understand the reference to CGRectZero in my code?

The first step creates a machine readable copy of your code and it is the only one interested in your header files. The second step takes the output of the first step and creates the machine code needed to implement your logic and the final step copies the code you need from frameworks. The third step isn’t always performed, when you create a framework for example. It is also only done once during the compilation of your program even if you have hundreds of source code files.

The linker (ld) goes through all the object (.o) files generated in step 2 and creates a list of unresolved references that it tries to find in the frameworks, the included frameworks in turn have unresolved references that are resolved in the same way. Finally just to make things more complicated some references are resolved at run time although the linker needs to know that they can be resolved.

/Michael