16

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.

Jeff
  • 623
  • 3
  • 8
  • 22

2 Answers2

20

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.

Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • 1
    Yeah, you're right about the problem. I'm solved the issue by simply not linking Project B and Project C to Project A. Projects B and C still reference Project A as a dependency, and so they're able to build just fine. Since clients will always be including Project A alongside these projects, all symbols are found and things just work. – Jeff Aug 01 '12 at 19:28
  • 1
    @Jeff how did you make A a "dependency" so the others could build, while not actually linking to (including) A in their builds? – johnbakers Apr 30 '16 at 13:39
  • 1
    @Rob I've noticed that in Xcode if I build a static library that only includes a header to another library, but does not link to the other library's binary, the build completes fine. If I instead do this with an actual program project (not a library) then there are undefined definitions in the linking stage (errors). I assume that when you build a library, "skipping" this part of the linking stage is normal, whereas actual programs, when built, do extra link checks, is that right? (and would that be what the compiler is actually doing if it is instructed to build a library?) – johnbakers Apr 30 '16 at 14:38
  • 1
    @johnbakers A static library is just a collection of unlinked `.o` files, so yes, that's expected. `.h` files are just promises that there will be symbols available at link time. They generally do not generate any code or allocations of their own (it's possible for them to do so, but it generally a mistake if they do so in C or ObjC; C++ is a different animal). Building a static library doesn't "skip this part of the linking stage." There is no linking stage when you build a static library. You compile to `.o` and then glue them together (archive) to `.a`. – Rob Napier Apr 30 '16 at 16:29
  • @RobNapier awesome, thanks. it can be quite hard to find details and general introductions to these topics. appreciate the great comment. – johnbakers Apr 30 '16 at 17:13
  • @RobNapier so if I distribute my static library without the 3rd party binaries included in the `.a`, how does the final user know which version of the 3rd party did I use to compile my static library? I would say it can be a problem if there's a version mismatch. – focs Jan 25 '17 at 13:33
  • 1
    @focs Correct. You have to tell them in the documentation. This is not a fixable problem. There is no simple solution to dependency management without a dependency manager (CocoaPods, Carthage, SPM). That said, you do not need a perfect version match in C/ObjC. A similar version will still link successfully. (Obviously if you've relied on behavior of a specific version, that could inject problems; that's not even solvable with frameworks.) – Rob Napier Jan 25 '17 at 14:04
  • @RobNapier is it possible to conditionally use a class from linked static library? E.g. if final binary can locate the lib, it uses the class defined in that lib. Otherwise, just cut off functionality provided by that static lib. – Yevhen Dubinin Nov 13 '17 at 11:58
  • @YevhenDubinin The feature you're looking for is called weak linking. https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.html – Rob Napier Nov 13 '17 at 14:12
  • @RobNapier is it applicable for static libraries? I tried the approach provided in the doc, but ran into [this issue](https://stackoverflow.com/questions/47345870/weak-library-results-in-symbols-not-found-for-architecture-linker-error). – Yevhen Dubinin Nov 20 '17 at 08:43
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.

Jonah
  • 17,918
  • 1
  • 43
  • 70