【问题标题】:Static Library Dependency not being included in binary静态库依赖项未包含在二进制文件中
【发布时间】:2011-07-01 07:06:43
【问题描述】:

我已经构建了一个依赖于 CFNetwork.framework 的静态库(我们称之为 A),该库已在 xCode 中成功构建。我已将 CFNetwork.framework 包含在“将二进制文件与库链接”构建阶段。这个静态库有自己的项目。

由于某种原因,当尝试在另一个项目中使用这个静态库(我们称之为 B)时,它在链接阶段失败,抱怨找不到 CFNetwork 的符号。

我已将 A 作为依赖项添加到 B 的目标中(这样 A 总是在 B 成功之前编译),并且我还将 A 添加到 B 的“Link Binary With Libraries”构建阶段。

有没有人遇到过类似的问题?

编辑:如果我将 CFNetwork.framework 添加到 B 的“Link Binary With Libraries”构建中,它将开始成功构建。

【问题讨论】:

  • 我遇到了完全相同的问题,但使用的是 MediaPlayer.framework。你找到解决方案了吗?
  • 是的...如果您有一个依赖于 MediaPlayer.framework 的静态库 A,您应该将 MediaPlayer.framework 链接到可执行文件(在上面的示例中为 B)。静态库不会相互“复制”

标签: ios


【解决方案1】:

是的,您还需要在项目B 中添加CFNetwork.framework 作为依赖项。

这是设置依赖项的正确方式。您需要在静态库A 的发行说明中记录对CFNetwork.framework 的依赖。

一定要看看Guidelines for Creating Frameworks,特别是“您的框架中要包含的内容”。您会看到 Apple 建议不要创建伞式框架(即在您的分布式静态库中包含类似 CFNetwork.framework 的内容)。

不要创建伞式框架

虽然可以使用 Xcode 创建伞式框架,但 所以对于大多数开发人员来说是不必要的,不推荐使用。苹果 使用伞式框架来掩饰它们之间的一些相互依赖关系 操作系统中的库。在几乎所有情况下,您都应该 能够将您的代码包含在单个标准框架包中。 或者,如果您的代码足够模块化,您可以创建 多个框架,但在这种情况下, 模块将是最小的或不存在的,不应保证 为他们制作一把雨伞。

如果您有很多依赖项,那么值得考虑使用像 Cocoapods 这样的依赖项管理工具。

【讨论】:

    猜你喜欢
    • 2012-12-21
    • 1970-01-01
    • 1970-01-01
    • 2017-07-25
    • 1970-01-01
    • 1970-01-01
    • 2011-12-24
    • 1970-01-01
    • 2019-12-30
    相关资源
    最近更新 更多