Linking static libraries, that share another static library

Question

I currently have a single Xcode project for a very large code base, I'll call it Project X, which I am dividing into a bunch of sub projects ( Projects A, B, C ).

So far, each of these projects compiles, on their own, just fine. They all produce static libraries. Project B and Project C are dependent on the static library produced by Project A in order to build.

I have another xcode project, Project Z, that requires the static libraries produced by Projects B and C. Herein lies the problem. When Project Z enters the linker phase, things blow up - duplicate symbols are found within the libs for Projects B and C for the code they originally linked against in Project A!

I'm pretty new to the world of static libraries, and I'm unsure of how to move forward with Project Z, or how to modify the other projects so that they are linking against the same Project A lib. I have a feeling it's not possible. What are my options here?

Edit:

I should clarify that Project B and Project C need to build into separate static libs because some clients will only require one or the other.

Also, I'm having this dilemma on both OSX and iOS platforms.

I realize that I could solve this problem on OSX by building the projects as dynamic libraries. However, I'd prefer not to do this, and it still leaves me with same issue on iOS.

Answer 1

Static libraries should never include other static libraries (or third party code in general). A static library is just a bundle of .o files glued together. So if you have multiple copies of the same information, it's going to blow up.

Each static library should just have its own code in it. The final application is responsible for linking all the required libraries together (including libraries required by libraries). This way there is exactly one copy of each thing linked.

Answer 2

This sounds like exactly the sort of problem CoacoaPods was created to solve. If you define pods for each of theses projects then Z should be able to determine and link against all of its dependencies all the way up the chain without introducing duplicate symbols.