[Brass]

TWO questions really. I'm developing an application that uses a small third party public domain C library. In the process, I've developed an Objective-C framework as a wrapper for the C library.

I would like to be able to distribute my application to users without them having to install any additional libraries, or even the framework separately. So hence these two questions:

1. When building my Framework in Project Builder, how do I get it to statically link to the 3rd party C library instead of dynamically link, so that the required objects will be compiled into the final product?

2. Similarly, when building the final application in Project Builder, how do I get it to statically compile in the required objects of the framework into the final product?

[Angus_D]

Originally posted by Brass:
1. When building my Framework in Project Builder, how do I get it to statically link to the 3rd party C library instead of dynamically link, so that the required objects will be compiled into the final product?

You need to obtain a static library. Static libraries end in ".a" instead of ".dylib" or being inside a framework.

2. Similarly, when building the final application in Project Builder, how do I get it to statically compile in the required objects of the framework into the final product?

Compile your framework as a static library. You can do this with a library target (not a framework target) and by changing one of the build settings, but I don't know exactly what it's called offhand. It was pretty self explanatory last time I looked.

However, you could consider bundling the frameworks withing your application bundle, in the Frameworks directory. Just set the installation path using the @executable_path hack, as documented all over the place, then add a copy files build phase.

[Brass]

Thanks for this advice. I've now built the framework using the static version of the library (which were available thankfully). Now I've just got to create a new static library target in addition to the default framework target (I may as well keep both targets).

For my current application, speed/performance is of the most importance, and the libraries and frameworks are quite small, so that additional code added to my application won't increase it's size too much.

[Brass]

Well, The Framework compiles and builds okay, statically linked to the 3rd party libraries. And I've created a second target to build a static library instead of a Framework.

The library appears to build okay. The only modification I made to the default settings for this target are to include some optimisation, and to add a ".a" to the end of the "FILE_NAME" build setting.

However, when I change my application project to use the new library, instead of the old framework, it fails during linking (everything compiles successfully). It gives the error "Undefined symbols: .objc_class_name_BlahBlah"

(where "BlahBlah" is the actual name of one of the classes defined in my library that I'm trying to statically link to).

Any ideas how to find out what I've done wrong?

NB: I've also tried it with no file extension on the library file (instead of ".a"), and it made no difference - same error. Is ".a" the correct file extension for an ObjC library file (static).

[Brass]

Okay, I've looked closer at the verbose output of the build in Project Builder, and have noticed a warning that was not shown in the brief top pane:

Warning: StandalonExecutable: Unknown extension on BlahBlah.a when linking with Standalone Executable

(where "BlahBlah" is the name of the static library I've created).

So what should the extension be on this library? Is there some build setting that I've missed when creating the library in the first place?

[Angus_D]

Your static library's build product name needs to have the "lib" prefix. like "libMyLib.a" or something.

[Brass]

Originally posted by Angus_D:
Your static library's build product name needs to have the "lib" prefix. like "libMyLib.a" or something.

you're kidding? And I thought that file extensions were arcane!

I might try this later. In the meantime, I've gone with the former suggestion of bundling the Framework within the application bundle. Seems to work nicely and doesn't require the user to run any installer. Any performance hit is probably negligible.