3

如果您正在构建一个将包含在其他人的代码中的商业 iOS SDK，并且您拥有获得许可的第三方库，那么是否有一种有效的方法可以通过不导出这些 3rd 方符号来简化库/框架结构静态库？

我很感激我可以指导开发人员检查重叠的符号，但我想尽量减少指令。即，只是希望他们将 lib 放入他们的项目中然后离开。我也不想导出我的第三方符号，因为它们可能会在以后的项目中发生变化。

4

2 回答 2

3

请参阅符号导出策略。你有几个选择：

  1. 将符号标记为静态（在这种情况下可能不可能，因为它们来自第 3 方）
  2. 使用导出的符号列表或未导出的符号列表
  3. 直接设置符号的可见性属性（同样，在这种情况下可能是不可能的）
  4. 编译时使用-fvisibility命令行选项（可能是你最好的选择）
  5. 使用弱进口
  6. 使用弱库

这些在上面的链接中进行了解释。

于 2012-08-11T23:53:42.850 回答
3

不幸的是，这里没有很多事情可以轻松完成。静态库只是一堆粘在一起的 .o 文件。没有链接器步骤来确定 .o 之间实际需要哪些片段。直到最后的链接步骤（由您的客户）才完成。

也就是说，您可以考虑以下几点：

  • 首先，尽可能避免在静态库中包含子库。如果客户有可能拥有同一个子库的其他副本，这真的很危险。由于您的子库已获得许可，因此您的情况似乎有所不同，因此客户不太可能拥有多个副本，但是例如，您永远不应该在静态库中包含 libcurl 的静态副本。您必须要求客户自己链接 libcurl，否则对他们来说事情会非常糟糕。（请参阅链接静态库，共享另一个静态库。）同样，这听起来可能不适用于您，但如果您有通用的开源库，请记住这一点。

  • 处理可见性的老派解决方案是将编译单元粘合在一起。这是“将所有 .c/.m 文件连接成一个大文件并编译它”的一种奇特方式。您标记为“静态”的任何函数在此编译单元之外都将不可见，因此不应导出。这也恰好增加了库内编译器内联和其他优化（特别是没有花哨的链接时优化）的可能性。

于 2012-08-12T02:57:55.967 回答