【问题标题】:Runtime ObjC symbol collision in static/dynamic library静态/动态库中的运行时 ObjC 符号冲突
【发布时间】:2020-06-23 03:56:49
【问题描述】:

我正在构建一个动态库,它依赖于我之前构建的另一个静态库。静态库依赖于 WebRTC。但是,新的动态库将用于 Swift 应用程序,该应用程序也依赖于 WebRTC。这在构建时导致了很多符号冲突,所以我followed this doc 并在动态库中添加了一个导出符号文件。

现在动态库和 Swift 应用程序都构建得很好,但是当 Swift 应用程序启动时,我收到了很多关于重复 ObjC 类符号的控制台警告:

objc[63026]: Class RTCCVPixelBuffer is implemented in both /path/to/the/dynamic/framework/binary and /path/to/existing/webrtc/in/the/swift/app. One of the two will be used. Which one is undefined.

我检查了我的动态框架,这些 WebRTC ObjC 符号都是本地(非外部)符号。现在我有两个问题:

  1. 本地符号冲突会导致任何运行时问题,例如未定义的应用行为和应用崩溃吗?我知道重复的全局符号不起作用,但是重复 本地 符号的最坏结果是什么?
  2. 是否需要这些本地符号,如何删除它们?我首先尝试通过在构建设置中设置 GENERATE_MASTER_OBJECT_FILESTRIP_STYLEDEPLOYMENT_POSTPROCESSING 来预链接静态库中的目标文件,希望在它们进入动态库之前解析所有符号,但我仍然可以在我的动态库二进制文件中看到这些本地 ObjC 类符号。我还尝试在Additional strip flags 中设置-R 选项以去除本地符号,但这也失败了。这些符号是必需的并且不能因为 ObjC 消息发送依赖于它们而被删除吗?解决此类符号冲突问题的正确方法是什么?

【问题讨论】:

  • 可以改为构建静态库吗?
  • @Cy-4AH 我实际上通过将库从静态更改为动态并添加导出符号文件来解决构建时间符号冲突。保持动态还有其他一些好处(小得多的工件等),所以我宁愿在动态框架中找到解决方案,除非不可能。
  • 静态框架更好。出了点问题,当所有库和框架都是静态的时,没有符号冲突。我不知道您在谈论哪些较小的工件,但是当您使用静态库时,应用程序实际上更小,因为未使用的目标文件未与应用程序链接。

标签: ios objective-c linker static-libraries symbols


【解决方案1】:

我最终使用objc_runtime_name attribute 为所有ObjC 接口添加前缀。这实质上将接口的元数据名称更改为指定的字符串参数,从而解决了重复符号问题。

【讨论】:

  • 但是您仍然有重复的符号,只是名称不同。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2020-08-01
  • 2014-11-23
  • 2020-11-03
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-04-07
相关资源
最近更新 更多