I’m working on two projects right now that have static library products, to be given to other developers to use in their projects: [Audiobus](http://audiob.us) and [The Amazing Audio Engine](http://theamazingaudioengine.com). In both cases, I’m making quite heavy use of my circular buffer code, [TPCircularBuffer](http://github.com/michaeltyson/TPCircularBuffer), which would result in duplicate symbol errors if the static library were linked with another project that used it.
In case the solution was useful to others, here’s how I worked around it: Use the preprocessor to rename the symbols automatically during the build phase.
This is done by adding a series of -DOldSymbol=NewSymbol flags to the ‘Other C Flags’ build setting – like -DTPCircularBuffer=ABCircularBuffer, for instance.
No more symbol conflicts.
…but duplicating the code and making the build and debugging difficult to understand. Why not ship a third library with the shared code or a single library with both dependencies and the buffer.
Rog: Cleanliness and ease of use, and conflict avoidance. What if your project already uses an older version of one of the dependencies, or one of the other utilities the library relies upon? Suddenly, dependency management gets incredibly complicated and annoying.
I don’t like the idea of forcing users to deal with that kind of complexity. At least, I wouldn’t like that, as a user.
I don’t really see how doing this makes the build hard to understand, or how it complicates debugging =)
Great stuff. Thanks! I ran into this exact same problem using your library template. Was desperate to avoid giving things ridiculous names to the avoid the issue. How I miss Java packages :p.
Pingback: Xcode下使用公用静态库，如何避免"Duplicate Symbol"错误？ - Xcode - 开发者第651290个问答
Oddly enough, this doesn’t seem to work with Categories, everything else it works great with. I think maybe it barfs on the ‘+’?