Question

We have a Windows application written in C++, part of which we are trying to port to Mac OS X. Our goal is to wrap the business logic into some libraries and build a Cocoa layer on top for the controller and the GUI. We will probably have several smaller apps using the same libraries so our first thought was to use dynamic libraries for the C++ code (unless there is a better way).
However, we are having some problems with achieving this. Our dynamic library complies fine (at least it looks like that) and we get a .dylib file which we link to in our app. The problem is that our app simply can’t find any of the .h files we are trying to include.
We have already checked that the .h files are being exported as well as checked the install name and made sure that the library is located in the correct directory. Also, we have followed Apple’s guide for creating and using dynamic libraries and found no special step we were missing.

My question here is in two parts:

1. Is there some obvious step we might be missing which is instrumental in exposing the interface (i.e. the .h files) that we should try before anything else?
2. We do suspect that the fault might be in the crappy C++ code we have inherited in this project. For instance, there is a lot of logic (implementation of methods) written directly in .h files and in some cases there isn’t even a corresponding .cpp file at all. So the .h files aren’t merely a description of the interface. This might not be the (solemn) problem as our app can’t even find the .h files from the library and they should at be least present.
   We really hope that we can avoid rewriting a lot of the code since the code base which needs to be ported is really large and (as usual) the deadline is close.

PS: We have so far only been working in Xcode 4.2 and have not tried with the command line tools yet.

Answer 1

Option 1

In this case, I would just add the directory containing the headers to the discovery paths for headers or libraries in Xcode. Depending on the layout, some approaches will be better than others.

Generally, you’ll use some combination of:

• HEADER_SEARCH_PATHS
• LIBRARY_SEARCH_PATHS
• USER_HEADER_SEARCH_PATHS
• or FRAMEWORK_SEARCH_PATHS

Which one is correct depends on the library you are using (e.g. these options can also affect the linker). When defining the discovery paths, you can add the suffix ** to denote a recursive search.

This is ideal because you will have fewer troubles keeping your xc projects in sync with their vs solutions.

Option 2

Some people really like some drag and drop support for their includes… I don’t, but this is the approach if there is so much disorganization that you can’t just do something as simple as add a search path:

• add the headers you need to the project
• add those headers to the copy headers build phase of the target
• repeat until it builds and be prepared for breakage when you merge/pull their updates.

that gets messy quickly, and takes hours to reconstruct when you want to reuse the library if there are collisions in header names.