5

我正在从 iOS 的源代码构建一个动态框架,并启用了位码(使用cmakexcodebuild)。我使用lipoandinstall_name_tool制作一个胖二进制文件和 update LC_ID_DYLIB,以便正确加载二进制文件。当我归档应用程序时,框架已正确签名并与应用程序打包在一起。这是的输出file

MyFramework: Mach-O universal binary with 3 architectures: [arm_v7: Mach-O dynamically linked shared library arm_v7] [arm_v7s] [arm64]
MyFramework (for architecture armv7):   Mach-O dynamically linked shared library arm_v7
MyFramework (for architecture armv7s):  Mach-O dynamically linked shared library arm_v7s
MyFramework (for architecture arm64):   Mach-O 64-bit dynamically linked shared library arm64

查看otool -l输出LC_ID_DYLIB显示:

Load command 4
          cmd LC_ID_DYLIB
      cmdsize 64
         name @rpath/MyFramework.framework/MyFramework (offset 24)
   time stamp 1 Thu Jan  1 01:00:01 1970
      current version 1.0.0
compatibility version 1.0.0

这一切似乎都是正确的。如果我将此档案上传到 App Store,它会被正确上传和处理。从 App Store 运行它后,由于加载了动态框架,它在启动后立即崩溃。众所周知,应用程序是从 App Store 上的 Bitcode 重新编译的,所以我通过导出为 Ad-Hoc 并按照Technical Note TN2432中的建议启用“Rebuild from Bitcode”选项来模拟这一点。检查 .ipa(启动后也崩溃)和有问题的框架,这是以下输出otool -l

Load command 3
          cmd LC_ID_DYLIB
      cmdsize 128
         name /Users/legoless/Downloads/ios/build/build-iphoneos/lib/Release/MyFramework_ios.framework/MyFramework_ios (offset 24)
   time stamp 1 Thu Jan  1 01:00:01 1970
      current version 1.0.0
compatibility version 1.0.0

所以很明显LC_ID_DYLIB这个库的 是不正确的,这是框架最初构建位置的绝对路径,然后再制作一个胖二进制文件。这在Rebuild from Bitcode步骤中被替换,但我不知道为什么甚至不知道此路径存储在现有Mach-O文件中的位置。我使用otoolobjdump工具试图在 Mach-O 二进制文件中找到引用,但没有运气。

实际上,另一个框架依赖于这个框架,这是目标框架的加载命令:

Load command 14
          cmd LC_LOAD_DYLIB
      cmdsize 64
         name @rpath/MyFramework.framework/MyFramework (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 1.0.0
compatibility version 1.0.0

再次使用 Bitcode 重建后,这里的引用也发生了变化:

Load command 13
          cmd LC_LOAD_DYLIB
      cmdsize 128
         name /Users/legoless/Downloads/ios/build/build-iphoneos/lib/Release/MyFramework_ios.framework/MyFramework_ios (offset 24)
   time stamp 2 Thu Jan  1 01:00:02 1970
      current version 1.0.0
compatibility version 1.0.0

这只发生在有问题的框架上,但不会发生在其他框架上,@rpath它保持原样。

我的问题仍然存在:

这个绝对路径引用存储在哪里?以及如何删除它,因此 Rebuild from Bitcode 不再影响它了?

谢谢!

4

2 回答 2

3

对此问题进行详细调查后发现,在 Mach-O 文件中包含位码的.xar存档存储了大量信息,包括链接器标志。此信息存储在存档的目录中,用于在位码重新编译时重新编译/重新链接库。

就我而言,我正在使用cmake构建框架,它将这些信息添加到链接器标志中。配置INSTALL_NAME_DIRBUILD_WITH_INSTALL_RPATH使用@rpath 有效地解决了这个问题,并且install_name_tool不再需要。

于 2017-01-14T05:49:23.117 回答
1

我遇到了完全相同的问题。接受的答案让我很接近,但是设置INSTALL_NAME_DIR参数本身并没有解决它,因为它不允许您将传递给链接器的完整值设置为 install_name (如您所料,只有目录)。

相反,我设置XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME了一次覆盖完整值的设置。显然这仅适用于 CMake 中的 XCode 生成器,但这对我想要的很好。总而言之,我的这个框架的 CMake 文件现在包含:

set_target_properties(${LIBRARY_NAME} PROPERTIES XCODE_ATTRIBUTE_LD_DYLIB_INSTALL_NAME "@rpath/${LIBRARY_NAME}.framework/${LIBRARY_NAME}")
set_target_properties(${LIBRARY_NAME} PROPERTIES BUILD_WITH_INSTALL_RPATH 1)
于 2017-09-21T10:48:00.430 回答