3

If you're building a commercial iOS SDK that will be included in other people's code and you have third party libraries that you have a license to, is there an effective way to simplify the library / framework structure by not exporting those 3rd party symbols in a static lib?

I appreciate I could instruct developers to check for overlapping symbols, but I'd like to minimize instructions. Ie, just want them to drop the lib into their project and off they go. I also do not want to export my third party symbols as they may change in later projects.

Blaze
  • 1,530
  • 2
  • 15
  • 24

2 Answers2

3

See Symbol Exporting Strategies. You have several options:

  1. marking symbols as static (probably not possible in this case since they come from a 3rd party)
  2. Use an exported symbols list or an unexported symbols list
  3. Set the visibility attribute of the symbol directly (again, probably not possible in this case)
  4. Use -fvisibility command line option when compiling (probably your best bet here)
  5. Use weak imports
  6. Use a weak library

These are explained at the link above.

user1118321
  • 25,567
  • 4
  • 55
  • 86
  • 2
    those seem to be Dylib design guidelines. on iOS there is no support (without significant hackage) for dylibs in Xcode. – Blaze Aug 13 '12 at 20:16
3

Unfortunately, there isn't a lot to be done here very easily. A static library is just a bunch of .o files glued together. There is no linker step to determine what pieces are actually needed between .o's. That's not done until the final link step (by your customer).

That said, there are some things you can think about:

  • First, whenever possible, avoid including sub-libraries inside of a static library. This is really dangerous if it's possible for the customer to have other copies of the same sub-library. Your situation seems to be difference since your sub-library is licensed, so the customer is unlikely to have multiple copies, but for example, you should never include a static copy of libcurl in your static library. You must ask the customer to link libcurl themselves, or else things will explode quite badly for them. (See Linking static libraries, that share another static library.) Again, this sounds like it may not apply to you, but keep it in mind if you have common open-source libraries in the mix.

  • An old-school solution for dealing with visibility is to glue together your compile units. This is a fancy way of saying "concatenate all your .c/.m files into one massive file and compile that." Any function you mark "static" will not be visible outside this compile unit, and so shouldn't be exported. This also happens to increase the possibility of compiler inlining and other optimizations (particularly without fancy link-time optimization) inside of your library.

Community
  • 1
  • 1
Rob Napier
  • 286,113
  • 34
  • 456
  • 610
  • I suspected as much. I'll probably prefix the third party classes so there won't be any conflicts. I have source code. really don't want multiple libs. plus, from a qa p.o.v. don't want to worry about different versions of the libs. – Blaze Aug 13 '12 at 20:21