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 and The Amazing Audio Engine. In both cases, I’m making quite heavy use of my circular buffer code, 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.
Add us on Facebook!
3 Comments
…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.